DOCSLIB.ORG

A Bottom-Up Approach to the Secure and Standardized Internet of Things Timothy Claeys

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Bottom-Up Approach to the Secure and Standardized Internet of Things Timothy Claeys Security for the internet of things : a bottom-up approach to the secure and standardized internet of things Timothy Claeys To cite this version: Timothy Claeys. Security for the internet of things : a bottom-up approach to the secure and stan- dardized internet of things. Computers and Society [cs.CY]. Université Grenoble Alpes, 2019. English. NNT : 2019GREAM062. tel-02948567 HAL Id: tel-02948567 https://tel.archives-ouvertes.fr/tel-02948567 Submitted on 24 Sep 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THÈSE Pour obtenir le grade de DOCTEUR DE LA COMMUNAUTÉ UNIVERSITÉ GRENOBLE ALPES Spécialité : Informatique Arrêté ministériel : 25 mai 2016 Présentée par Timothy Claeys Thèse dirigée par Bernard Tourancheau Professeur, Université Grenoble Alpes et coencadrée par Franck Rousseau Maitre de Conférence, Grenoble INP préparée au sein de Laboratoire d’Informatique de Grenoble (LIG) dans l’École Doctorale Mathématiques, Sciences et Technologies de l’Information, Informatique (EDMSTII). Sécurité pour l’Internet des Objets: Une approche de bas en haut pour un Internet des Objets sécurisé et normalisé Security for the Internet of Things: A bottom-up approach to the secure and standardized Internet of Things Thèse soutenue publiquement le 19 décembre 2019, devant le jury composé de : Bernard Tourancheau Professeur, Université Grenoble Alpes, Directeur de thèse Marine Minier Professeure, Université de Lorraine, Rapporteur Laurent Toutain Professeur, IMT Atlantique Bretagne-Pays de la Loire, Président Congduc Pham Professeur, Université de Pau et des Pays de l’Adour, Examinateur Mathieu Cunche Maître de Conférences, INSA Lyon, Examinateur Franck Rousseau Maître de Conférences, Grenoble INP, Co-Encadrant de thèse Abstract The rapid expansion of the IoT has unleashed a tidal wave of cheap Internet-connected hardware. For many of these products, security was merely an afterthought. Due to their advanced sensing and actuating functionalities, poorly-secured IoT devices endanger the privacy and safety of their users. While the IoT contains hardware with varying capabilities, in this work, we primarily focus on the con- strained IoT. The restrictions on energy, computational power, and memory limit not only the processing capabilities of the devices but also their capacity to protect their data and users from attacks. To secure the IoT, we need several building blocks. We structure them in a bottom-up fashion where each block provides security services to the next one. The first cornerstone of the secure IoT relies on hardware-enforced mechanisms. Various security fea- tures, such as secure boot, remote attestation, and over-the-air updates, rely heavily on its support. Since hardware security is often expensive and cannot be applied to legacy systems, we alternatively discuss software-only attestation. It provides a trust anchor to remote systems that lack hardware support. In the setting of remote attestation, device identification is paramount. Hence, we dedicated a part of this work to the study of physical device identifiers and their reliability. The IoT hardware also frequently provides support for the second building block: cryptography. It is used abundantly by all the other security mechanisms, and recently much research has focussed on lightweight cryptographic algorithms. We studied the performance of the recent lightweight cryptographic algorithms on constrained hardware. A third core element for the security of the IoT is the capacity of its networking stack to protect the com- munications. We demonstrate that several optimization techniques expose vulnerabilities. For example, we show how to set up a covert channel by exploiting the tolerance of the Bluetooth LE protocol towards the naturally occurring clock drift. It is also possible to mount a denial-of-service attack that leverages the expensive network join phase. As a defense, we designed an algorithm that almost completely alleviates the overhead of network joining. The last building block we consider is security architectures for the IoT. They guide the secure inte- gration of the IoT with the traditional Internet. We studied the IETF proposal concerning the constrained authentication and authorization framework, and we propose two adaptations that aim to improve its se- curity. Finally, the deployment of the IETF architecture heavily depends on the security of the underlying com- munication protocols. In the future, the IoT will mainly use the object security paradigm to secure data in flight. However, until these protocols are widely supported, many IoT products will rely on traditional security protocols, i.e., TLS and DTLS. For this reason, we conducted a performance study of the most crit- ical part of the protocols: the handshake phase. We conclude that while the DTLS handshake uses fewer packets to establish the shared secret, TLS outperforms DTLS in lossy networks. ii Résumé La rapide expansion du marché de l’IoT a permis de relier de plus en plus de matériels bon marché à l’Internet. Pour bon nombre de ces objets, la sécurité ne constitue pas une priorité. En raison de leurs fonctionnalités avancées de détection et de manipulation, ces produits IoT mal sécurisés mettent en dan- ger la vie privée et la sécurité de leurs utilisateurs. Bien que l’IoT englobe des objets connectés de capacités variables, dans ces travaux, nous nous concen- trons sur les équipements contraints en énergie, en ressources mémoires, et à faible puissance de calcul. Ces restrictions limitent non seulement la possibilité de traitements, mais aussi la capacité à protéger les données et les utilisateurs. Afin de sécuriser l’IoT, nous identifions plusieurs éléments de bases permettant de fournir des services de sécurité sur l’ensemble d’un équipement. L’implémentation des mécanismes de sécurité au niveau matériel constitue un premier pilier pour l’IoT sécurisé. Diverses fonctions, telles que le démarrage sécurisé, l’attestation à distance et les mises à jour "over-the-air", dépendent en effet fortement de son support. Comme l’implémentation de la sécurité matérielle est souvent coûteuse et ne peut être appliquée aux systèmes existants, nous étudions l’attestation purement logicielle. Cette méthode fournit une racine de confiance aux systèmes distants qui ne support- ent pas la sécurité au niveau matériel. Dans le cadre de l’attestation à distance, l’identification de l’appareil est primordiale. Une partie de ce travail est donc consacrée à l’étude des identificateurs physiques des dispositifs et de leur fiabilité. L’IoT sécurisé repose sur un deuxième élément clé: la cryptographie. Cette dernière est abondamment utilisée par tous les autres mécanismes de sécurité et largement étudiée. Nous étudions les performances des algorithmes cryptographiques récents pour les dispositifs contraints. Un troisième élément central pour sécuriser l’IoT est la capacité de la pile protocolaire à sécuriser les communications. Nous montrons par exemple qu’il est possible d’exploiter la tolérance du BLE à la dérive d’horloge pour établir un canal couvert. D’autre part, il est possible de monter une attaque de déni de service en exploitant les phases énergivores du réseau, notamment la phase d’attache. Nous proposons dans ces travaux un algorithme défensif qui réduit quasiment à néant les surcoûts liés à la connexion au réseau. Les architectures de sécurité constituent le dernier pilier pour la sécurité de l’IoT. Elles permettent en effet de guider le déploiement d’un IoT sécurisé à grande échelle. Après avoir étudié la proposition de l’IETF de schéma d’authentification et d’autorisation pour l’IoT, nous proposons deux pistes d’amélioration de la sécurité. Enfin, la mise en place d’une architecture de sécurité implique le choix du protocole. Dans le con- texte des réseaux contraints énergétiquement, le critère déterminant sera la consommation. Même si, à l’avenir, l’IoT utilisera principalement le paradigme d’objets sécurisés pour protéger les données, tant que ces derniers ne seront pas largement supportés, de nombreux produits IoT s’appuieront sur les protocoles de sécurité traditionnels tels que TLS et DTLS. C’est pourquoi nous réalisons une étude de performance sur la partie la plus critique de ces protocoles : l’établissement du secret partagé. Nous montrons que, même si le "handshake" DTLS utilise moins de paquets pour établir le secret partagé, TLS obtient des meilleurs résultats dans les réseaux avec pertes. iii Acknowledgments I would like to express my sincere gratitude to my supervisors, Franck Rousseau and Bernard Tourancheau, for their guidance over the past four years. They allowed me to independently develop my research while supporting me with excellent advice. I am grateful for the opportunities they have given me which have lead to many unforgettable experiences around the world. Additionally, I would like to thank all the members of the jury for their compelling questions and com- ments during the defense. I am grateful to Prof. Laurent Toutain and Prof. Marine Minier, for having re- viewed my entire manuscript, and Mr. Mathieu Cunche and Prof. Congduc Pham, for their helpful remarks on my work and presentation. A major part of my research was done in the context of the IoTize project. I would like to thank Vincent and Francis from the eponymous company who aided me in understanding many complex topics related to microcontrollers. Furthermore, I wish to thank all the wonderful people in the Drakkar research group. I have learned from everyone in the team and their help has been invaluable in completing this work. I particularly enjoyed all the time I spent with Henry and Etienne during breaks, talking about a wide variety of scientific topics.
Load more

Recommended publications
  • Course 5 Lesson 2
    This material is based on work supported by the National Science Foundation under Grant No. 0802551 Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author (s) and do not necessarily reflect the views of the National Science Foundation C5L3S1 With the advent of the Internet, social networking, and open communication, a vast amount of information is readily available on the Internet for anyone to access. Despite this trend, computer users need to ensure private or personal communications remain confidential and are viewed only by the intended party. Private information such as a social security numbers, school transcripts, medical histories, tax records, banking, and legal documents should be secure when transmitted online or stored locally. One way to keep data confidential is to encrypt it. Militaries,U the governments, industries, and any organization having a desire to maintain privacy have used encryption techniques to secure information. Encryption helps to boost confidence in the security of online commerce and is necessary for secure transactions. In this lesson, you will review encryption and examine several tools used to encrypt data. You will also learn to encrypt and decrypt data. Anyone who desires to administer computer networks and work with private data must have some familiarity with basic encryption protocols and techniques. C5L3S2 You should know what will be expected of you when you complete this lesson. These expectations are presented as objectives. Objectives are short statements of expectations that tell you what you must be able to do, perform, learn, or adjust after reviewing the lesson.
    [Show full text]
  • Chapter 12 Pretty Good Privacy (PGP)
    Chapter 12 Pretty Good Privacy (PGP) With the explosively growing reliance on electronic mail for every conceivable pur- pose, there grows a demand for authentication and confidentiality services. Two schemes stand out as approaches that enjoy widespread use: Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extension (S/MIME). The latter is a security en- hancement to the MIME Internet e-mail format standard, based on technology from RSA Data Security. Although both PGP and S/MIME are on an IETF standards track, it appears likely that S/MIME will emerge as the industry standard for commercial and organisational use, while PGP will remain the choice for personal e-mail security for many users. In this course we will only be looking at PGP. S/MIME is discussed in detail in the recommended text. 12.1 Background PGP is a remarkable phenomenon. Largely the effort of a single person, Phil Zimmer- mann, PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. In essence what Zimmermann has done is the following: 1. Selected the best cryptographic mechanisms (algorithms) as building blocks. 2. Integrated these algorithms into a general purpose application that is independent of operating system and processor and that is based on a small set of easy to use commands. 3. Made the package and its source code freely available via the Internet, bulletin boards, and commercial networks such as America On Line (AOL). 4. Entered into an agreement with a company (Viacrypt, now Network Associates) to provide a fully compatible low cost commercial version of PGP.
    [Show full text]
  • Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3
    Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3 Phong Q. Nguyen CNRS/Ecole´ normale sup´erieure D´epartement d’informatique 45 rue d’Ulm, 75230 Paris Cedex 05, France. [email protected] http://www.di.ens.fr/˜pnguyen Abstract. More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary soft- ware, one cannot say much unless one proceeds to reverse-engineering, and history tends to show that bad cryptography is much more frequent than good cryptography there. Open source software thus sounds like a good solution, but the fact that a source code can be read does not imply that it is actually read, especially by cryptography experts. In this paper, we illustrate this point by examining the case of a basic In- ternet application of cryptography: secure email. We analyze parts of thesourcecodeofthelatestversionofGNUPrivacyGuard(GnuPGor GPG), a free open source alternative to the famous PGP software, com- pliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We ob- serve several cryptographic flaws in GPG v1.2.3. The most serious flaw has been present in GPG for almost four years: we show that as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer’s private key in less than a second on a PC. As a consequence, ElGamal signatures and the so-called ElGamal sign+encrypt keys have recently been removed from GPG.
    [Show full text]
  • A History of End-To-End Encryption and the Death of PGP
    25/05/2020 A history of end-to-end encryption and the death of PGP Hey! I'm David, a security engineer at the Blockchain team of Facebook (https://facebook.com/), previously a security consultant for the Cryptography Services of NCC Group (https://www.nccgroup.com). I'm also the author of the Real World Cryptography book (https://www.manning.com/books/real-world- cryptography?a_aid=Realworldcrypto&a_bid=ad500e09). This is my blog about cryptography and security and other related topics that I Ûnd interesting. A history of end-to-end encryption and If you don't know where to start, you might want to check these popular the death of PGP articles: posted January 2020 - How did length extension attacks made it 1981 - RFC 788 - Simple Mail Transfer Protocol into SHA-2? (/article/417/how-did-length- extension-attacks-made-it-into-sha-2/) (https://tools.ietf.org/html/rfc788) (SMTP) is published, - Speed and Cryptography the standard for email is born. (/article/468/speed-and-cryptography/) - What is the BLS signature scheme? (/article/472/what-is-the-bls-signature- This is were everything starts, we now have an open peer-to-peer scheme/) protocol that everyone on the internet can use to communicate. - Zero'ing memory, compiler optimizations and memset_s (/article/419/zeroing-memory- compiler-optimizations-and-memset_s/) 1991 - The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations The US government introduces the 1991 Senate Bill 266, (/article/461/the-9-lives-of-bleichenbachers- which attempts to allow "the Government to obtain the cat-new-cache-attacks-on-tls- plain text contents of voice, data, and other implementations/) - How to Backdoor Di¸e-Hellman: quick communications when appropriately authorized by law" explanation (/article/360/how-to-backdoor- from "providers of electronic communications services di¸e-hellman-quick-explanation/) and manufacturers of electronic communications - Tamarin Prover Introduction (/article/404/tamarin-prover-introduction/) service equipment".
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Secure Industrial Device Connectivity with Low-Overhead TLS
    Secure Industrial Device Connectivity with Low-Overhead TLS Tuesday, October 3, 2017 1:10PM-2:10PM Chris Conlon - Engineering Manager, wolfSSL - B.S. from Montana State University (Bozeman, MT) - Software engineer at wolfSSL (7 years) Contact Info: - Email: [email protected] - Twitter: @c_conlon A. – B. – C. – D. – E. F. ● ● ● ○ ● ○ ● ○ ● Original Image Encrypted using ECB mode Modes other than ECB ● ○ ● ○ ● ● ● ● ○ ● ● ● ● ○ ● ○ ○ ○ ○ ● ○ ● ● ● ● ○ ● ● ○ By Original schema: A.J. Han Vinck, University of Duisburg-EssenSVG version: Flugaal - A.J. Han Vinck, Introduction to public key cryptography, p. 16, Public Domain, https://commons.wikimedia.org/w/index.php?curid=17063048 ● ○ ● ○ ■ ■ ■ ● ○ ■ ● ● ● ● ● ○ ● ● ● ● ● ● ● ○ ○ ○ ○ ● “Progressive” is a subjective term ● These slides talk about crypto algorithms that are: ○ New, modern ○ Becoming widely accepted ○ Have been integrated into SSL/TLS with cipher suites ● ChaCha20 ● Poly1305 ● Curve25519 ● Ed25519 Created by Daniel Bernstein a research professor at the University of Illinois, Chicago Chacha20-Poly1305 AEAD used in Google over HTTPS Ed25519 and ChaCha20-Poly1305 AEAD used in Apple’s HomeKit (iOS Security) ● Fast stream cipher ● Based from Salsa20 stream cipher using a different quarter-round process giving it more diffusion ● Can be used for AEAD encryption with Poly1305 ● Was published by Bernstein in 2008 Used by ● Google Chrome ● TinySSH ● Apple HomeKit ● wolfSSL ● To provide authenticity of messages (MAC) ● Extremely fast in comparison to others ● Introduced by a presentation given from Bernstein in 2002 ● Naming scheme from using polynomial-evaluation MAC (Message Authentication Code) over a prime field Z/(2^130 - 5) Used by ● Tor ● Google Chrome ● Apple iOS ● wolfSSL Generic Montgomery curve. Reference 5 Used by ● Tera Term ● GnuPG ● wolfSSL Generic Twisted Edwards Curve.
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • No.Ntnu:Inspera:2546742.Pdf (10.61Mb)
    Krishna Shingala An alternative to the Public Key Krishna Shingala Infrastructure for the Internet of Things Master’s thesis in Communication Technology Supervisor: Danilo Gligoroski, Katina Kralevska, Torstein Heggebø Master’s thesis Master’s June 2019 An alternative to PKI for IoT PKI for to An alternative NTNU Engineering Communication Technology Communication Department of Information Security and Department of Information Faculty of Information Technology and Electrical Technology of Information Faculty Norwegian University of Science and Technology of Science University Norwegian An alternative to the Public Key Infras- tructure for the Internet of Things Krishna Shingala Submission date: June 2019 Responsible professor: Danilo Gligoroski, IIK, NTNU Supervisor: Danilo Gligoroski, IIK, NTNU Co-Supervisor: Katina Kralevska, IIK, NTNU Co-Supervisor: Torstein Heggebø, Nordic Semiconductor ASA Norwegian University of Science and Technology Department of Information Technology and Electrical Engineering Title: An alternative to the Public Key Infrastructure for the Internet of Things Student: Krishna Shingala Problem description: Internet of Things(IoT) enables participation of constrained devices on the Internet. Limited resources, bandwidth, and power on the devices have led to new protocols. Some examples of IoT driven and driving protocols are: – MQTT, CoAP that are application protocols for IoT; – 6LoWPAN enables efficient support of IPv6 on low power lossy networks; – CBOR enables concise data formatting; and – DTLS enables secure channel establishment over unreliable transport like the UDP. Security is one of the key factors for the success of IoT. TLS/DTLS secures the channel between the servers and the devices. Confidentiality is an important aspect of such a secure channel. Establishing the identity of an entity another.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • 7) Internet of Things a Survey on the Security of Iot Frameworks
    Journal of Information Security and Applications 38 (2018) 8–27 Contents lists available at ScienceDirect Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa Internet of Things: A survey on the security of IoT frameworks ∗ Mahmoud Ammar a, , Giovanni Russello b, Bruno Crispo a a Department of Computer Science, KU Leuven University, Heverlee, 3001, Belgium b Department of Computer Science, University of Auckland, Private Bag 92019, Auckland 1142, New Zealand a r t i c l e i n f o a b s t r a c t Article history: The Internet of Things (IoT) is heavily affecting our daily lives in many domains, ranging from tiny wear- able devices to large industrial systems. Consequently, a wide variety of IoT applications have been devel- Keywords: oped and deployed using different IoT frameworks. An IoT framework is a set of guiding rules, protocols, Internet of Things and standards which simplify the implementation of IoT applications. The success of these applications IoT mainly depends on the ecosystem characteristics of the IoT framework, with the emphasis on the security Framework mechanisms employed in it, where issues related to security and privacy are pivotal. In this paper, we sur- Platform vey the security of the main IoT frameworks, a total of 8 frameworks are considered. For each framework, Security we clarify the proposed architecture, the essentials of developing third-party smart apps, the compati- ble hardware, and the security features. Comparing security architectures shows that the same standards used for securing communications, whereas different methodologies followed for providing other security properties.
    [Show full text]
  • Analysis of DTLS Implementations Using Protocol State Fuzzing
    Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Brostean and Bengt Jonsson, Uppsala University; Robert Merget, Ruhr-University Bochum; Joeri de Ruiter, SIDN Labs; Konstantinos Sagonas, Uppsala University; Juraj Somorovsky, Paderborn University https://www.usenix.org/conference/usenixsecurity20/presentation/fiterau-brostean This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Bro¸stean˘ Bengt Jonsson Robert Merget Joeri de Ruiter Uppsala University Uppsala University Ruhr University Bochum SIDN Labs Konstantinos Sagonas Juraj Somorovsky Uppsala University Paderborn University Abstract reach 11.6 billion by 2021 [26]. This will constitute half of all devices connected to the Internet, with the percentage set to Recent years have witnessed an increasing number of proto- grow in subsequent years. Such trends also increase the need cols relying on UDP. Compared to TCP, UDP offers perfor- to ensure that software designed for these devices is properly mance advantages such as simplicity and lower latency. This scrutinized, particularly with regards to its security. has motivated its adoption in Voice over IP, tunneling techno- DTLS is also used as one of the two security protocols in logies, IoT, and novel Web protocols. To protect sensitive data WebRTC, a framework enabling real-time communication. exchange in these scenarios, the DTLS protocol has been de- WebRTC can be used, for example, to implement video con- veloped as a cryptographic variation of TLS.
    [Show full text]