Mobile Oss Analysis Report for the Computer Security Exam at the Politecnico Di Torino

Total Page:16

File Type:pdf, Size:1020Kb

Mobile Oss Analysis Report for the Computer Security Exam at the Politecnico Di Torino Mobile OSs analysis Report for the Computer Security exam at the Politecnico di Torino Alessio Canepa (207687) Andrea Marcelli (209051) tutor: Andrea Atzeni June 2015 1 Indice 1 Introduzione6 1.1 Il mercato dei dispositivi mobili...........................6 1.2 Il problema della sicurezza..............................6 1.2.1 Differenze tra sicurezza su mobile e su fisso.................7 1.2.2 Obiettivi di un attacco............................8 1.2.3 Canali di attacco...............................9 1.2.4 Esempio di malware: SimpLocker, un ransomware per Android...... 10 1.2.5 Proteggersi dagli attacchi.......................... 13 1.3 Il modello dell'analisi di sicurezza.......................... 14 1.4 Conclusioni...................................... 15 2 Ubuntu Touch 17 2.1 Modalit`adell'analisi di sicurezza........................... 17 2.2 Introduzione...................................... 18 2.2.1 Poca integrazione tra S.O. mobili e fissi................... 18 2.2.2 Convergenza.................................. 18 2.3 Architettura...................................... 19 2.3.1 LXC - Linux Container............................ 19 2.3.2 Mir....................................... 20 2.3.3 Unity 8.................................... 20 2.3.4 Applicazioni.................................. 21 2.4 Modello di sicurezza del sistema operativo..................... 23 2.5 Tecniche di confinamento delle applicazioni..................... 23 2.5.1 La necessit`adi confinare le applicazioni in Ubuntu............. 23 2.5.2 Introduzione ad AppArmor......................... 24 2.5.3 AppArmor profile............................... 25 2.5.4 Policy Groups................................. 26 2.5.5 Gestione autorizzazioni: Trusted Helpers.................. 28 2.5.6 Condivisione contenuti: Content Hub.................... 29 2.6 Store.......................................... 31 2.6.1 Creazione e firma digitale delle applicazioni................ 31 2.6.2 Upload, controllo e firma digitale dello store................ 32 2.6.3 Download e verifica della firma digitale................... 32 2 2.7 Memorizzazione dati critici.............................. 33 2.7.1 GNOME Keyring e AppArmor....................... 33 2.7.2 Credenziali web: Ubuntu online accounts.................. 33 2.8 Cifratura dati utente................................. 33 2.8.1 Introduzione a eCryptfs........................... 33 2.8.2 Funzionamento di eCryptfs.......................... 34 2.9 Protezione dell'accesso................................ 35 2.10 Altri elementi di sicurezza.............................. 36 2.10.1 GSettings/dconf................................ 36 2.10.2 Display manager............................... 36 2.10.3 Environment variables............................ 37 2.10.4 Segnali tra processi.............................. 37 2.10.5 Protezione da remoto............................. 37 2.10.6 Certificati................................... 37 2.11 Vulnerabilit`anote................................... 38 2.12 Conclusioni...................................... 38 3 CyanogenMod 40 3.1 Modalit`adell'analisi di sicurezza........................... 40 3.2 Introduzione...................................... 41 3.2.1 Storia..................................... 41 3.2.2 Differenze con Android............................ 41 3.2.3 Distribuzione................................. 41 3.2.4 Device Rooted................................. 42 3.3 Tecniche di confinamento delle applicazioni..................... 42 3.3.1 Il modello Android.............................. 42 3.3.2 Gestione dei permessi............................. 43 3.3.3 Gestione privilegi di root........................... 44 3.4 Store.......................................... 45 3.5 Componenti di sicurezza aggiuntivi......................... 45 3.5.1 Whisperpush................................. 45 3.5.2 Protezione da remoto: Device Finder.................... 46 3.6 Cifratura dati utente................................. 48 3.7 Protezione dell'accesso................................ 49 3.8 Conclusioni...................................... 50 3 4 Tizen 51 4.1 Modalit`adell'analisi di sicurezza........................... 51 4.2 Introduzione...................................... 52 4.2.1 Tizen, \The OS of Everything"....................... 52 4.2.2 Storia..................................... 52 4.2.3 Le architetture supportate.......................... 53 4.2.4 Le applicazioni................................ 53 4.2.5 Strumenti di sviluppo............................. 54 4.3 Architettura...................................... 54 4.3.1 Kernel..................................... 54 4.3.2 Core...................................... 54 4.3.3 Framework Nativo.............................. 55 4.3.4 Framework Web................................ 56 4.3.5 Web Runtime................................. 56 4.4 Modello di sicurezza del sistema operativo..................... 56 4.4.1 L'utente.................................... 57 4.4.2 Le applicazioni................................ 57 4.4.3 Il sistema................................... 58 4.4.4 I principali componenti............................ 58 4.5 Tecniche di confinamento delle applicazioni..................... 59 4.5.1 Smack - Simplified Mandatory Access Control Kernel........... 59 4.5.2 Smack in Tizen................................ 62 4.5.3 UserID e GroupID.............................. 62 4.5.4 The three domain model........................... 63 4.5.5 Cynara..................................... 64 4.5.6 Commenti sul modello del controllo degli accessi in Tizen......... 66 4.5.7 Il sistema dei privilegi............................ 67 4.5.8 Firma delle applicazioni........................... 69 4.5.9 Installazione delle applicazioni........................ 70 4.5.10 Esecuzione delle applicazioni......................... 71 4.5.11 Vasum..................................... 72 4.6 Criticit`aprogettuali ed implementative delle applicazioni............. 74 4.6.1 Conversione automatica della applicazioni................. 74 4.6.2 WebGL.................................... 75 4.6.3 XSS...................................... 77 4.7 Store.......................................... 78 4 4.7.1 Il processo di revisione............................ 79 4.7.2 Connessione alla Store............................ 80 4.7.3 Store non ufficiali............................... 81 4.8 Cifratura........................................ 81 4.8.1 Cifratura applicazioni Web.......................... 81 4.9 Componenti di sicurezza aggiuntivi......................... 81 4.9.1 Tizen Key Manager.............................. 82 4.9.2 Secure Storage................................ 85 4.9.3 Content Security and Reputation Framework................ 85 4.9.4 Wifi Security................................. 88 4.9.5 Gestione dei certificati SSL.......................... 88 4.9.6 Tecniche di mitigazione degli exploit.................... 90 4.10 Protezione dell'accesso................................ 91 4.11 Vulnerabilit`anote................................... 92 4.12 Analisi Sperimentale................................. 93 4.12.1 Test Smack label............................... 93 4.12.2 Test ASLR.................................. 93 4.12.3 Test DEP................................... 94 4.13 Conclusioni...................................... 95 5 Conclusioni 96 6 Appendice 100 6.1 Memorizzazione dati critici.............................. 100 6.1.1 GNOME Keyring............................... 100 6.2 Sicurezza delle connessioni di rete.......................... 102 6.2.1 GSM...................................... 102 6.2.2 WiFi...................................... 103 6.3 Address Space Layout Randomization........................ 105 6.4 Data Execution Prevention.............................. 106 6.5 Modelli per il controllo degli accessi......................... 106 6.5.1 Discretionary access control......................... 107 6.5.2 Mandatory Access Control.......................... 107 6.6 LXC / Linux Containers............................... 107 5 1 Introduzione 1.1 Il mercato dei dispositivi mobili Il vertiginoso sviluppo tecnologico che ha caratterizzato l'ultimo ventennio ha portato diverse innovazioni, permettendo di lanciare sul mercato numerosi dispositivi innovativi. I progressi sulla \portabilit`a"della tecnologia hanno giocato un ruolo essenziale: sono nati nuovi dispositivi tascabili che hanno permesso di soddisfare la crescente necessit`adi archiviazione di dati e di connettivit`ain movimento. Il mercato dei dispositivi mobili, ha reso \portabili" gran parte delle funzionalit`afino a quel momento ristrette ai soli computer desktop, introducendo i nuovi smartphone, tablet e computer portatili, tutti dotati di caratteristiche necessarie per un costante utilizzo al di fuori dei tradizionali confini aziendali e domestici. Considerando i soli dispositivi in grado di connettersi ad internet, il loro numero ha recentemente superato quello della popolazione mondiale: i dati [1] stimano 7.3 miliardi di dispositivi contro 7.2 miliardi di persone. Di questi pi`udi 1.2 miliardi sono telefoni cellulari e il loro numero `e destinato a crescere, raggiungendo i 4 miliardi nel 2018 [2], con un forte sviluppo del mercato asiatico, soprattutto in Cina ed India. Sebbene il termine dispositivo mobile si riferisca ad un insieme di dispositivi molto vasto, come tecnologie wearable, smartphone, fotocamere ed altri, nel corso del report sar`autilizzato per indicare solo i telefoni cellulari di ultima generazione (smartphone) ed i tablet. In modo
Recommended publications
  • FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Kernel Crypto
    FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Kernel Crypto API Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-2.0.0 Date: December 7, 2018 Document Version 1.1 ©Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux 7 Kernel Crypto API Cryptographic Module Security Policy December 07, 2018 Author: Atsec Information Security Contributing Authors: Oracle Linux Engineering Oracle Security Evaluations – Global Product Security Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2018, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 7 Kernel Crypto API Cryptographic
    [Show full text]
  • Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives
    Self-encrypting deception: weaknesses in the encryption of solid state drives Carlo Meijer Bernard van Gastel Institute for Computing and Information Sciences School of Computer Science Radboud University Nijmegen Open University of the Netherlands [email protected] and Institute for Computing and Information Sciences Radboud University Nijmegen Bernard.vanGastel@{ou.nl,ru.nl} Abstract—We have analyzed the hardware full-disk encryption full-disk encryption. Full-disk encryption software, especially of several solid state drives (SSDs) by reverse engineering their those integrated in modern operating systems, may decide to firmware. These drives were produced by three manufacturers rely solely on hardware encryption in case it detects support between 2014 and 2018, and are both internal models using the SATA and NVMe interfaces (in a M.2 or 2.5" traditional form by the storage device. In case the decision is made to rely on factor) and external models using the USB interface. hardware encryption, typically software encryption is disabled. In theory, the security guarantees offered by hardware encryp- As a primary example, BitLocker, the full-disk encryption tion are similar to or better than software implementations. In software built into Microsoft Windows, switches off software reality, we found that many models using hardware encryption encryption and completely relies on hardware encryption by have critical security weaknesses due to specification, design, and implementation issues. For many models, these security default if the drive advertises support. weaknesses allow for complete recovery of the data without Contribution. This paper evaluates both internal and external knowledge of any secret (such as the password).
    [Show full text]
  • Namespacing in Selinux
    Namespacing in SELinux Linux.conf.au 2018 Sydney, Australia James Morris [email protected] Introduction ● Who am I? – Linux security subsystem maintainer ● Previously: Crypto API, Netfilter, SELinux, LSM, IPSec, MCS, sVirt ● Recovering manager ● blog.namei.org ● @xjamesmorris ● Overview – Briefly review technologies – Discuss requirements – SELinux namespace prototype – Current work: inode labeling – Future work SELinux ● Label-based mandatory access control (MAC) – Set security labels on: ● Subjects ● Objects – Define permissions – Centrally managed policy – Enforced by kernel ● Generalized ● Separation of policy and mechanism Linux Security Modules (LSM) ● Kernel API for access control ● Hooks – Located at security decision points – All security relevant information available – Race-free ● Kind of like Netfilter but for the whole kernel ● Pluggable: Smack, SELinux, AppArmor etc. Linux Namespaces ● Private views of global resources – mount, network, ipc, pid, user, uts, cgroup ● APIs: clone(2), setns(2), unshare(2) ● See also: pam_namespace(8) ● Uses: – Sandboxes – Containers – Multi-level security (!) ● No namespacing of LSM or other security APIs Containers ● Not a Thing ™ ● Actually namespaces + cgroups + magic – Docker, lxc, lxd etc. ● Very popular ● Kernel security APIs not containerized, e.g. – Limits functionality for OS-like containers – SELinux on Fedora-based distros pretends to be disabled inside container, and yet … ! Use Cases ● Enable SELinux confinement within a container – Currently runs as one global label and appears
    [Show full text]
  • Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami
    Speeding Up Linux Disk Encryption Ignat Korchagin @ignatkn $ whoami ● Performance and security at Cloudflare ● Passionate about security and crypto ● Enjoy low level programming @ignatkn Encrypting data at rest The storage stack applications @ignatkn The storage stack applications filesystems @ignatkn The storage stack applications filesystems block subsystem @ignatkn The storage stack applications filesystems block subsystem storage hardware @ignatkn Encryption at rest layers applications filesystems block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers DBMS, PGP, OpenSSL, Themis applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers Cons: ● no visibility into the implementation ● no auditability ● sometimes poor security https://support.microsoft.com/en-us/help/4516071/windows-10-update-kb4516071 @ignatkn Block
    [Show full text]
  • Analysis of an Encrypted HDD
    Analysis of an encrypted HDD J. Czarny, R. Rigo May 11, 2015 Abstract The idea of this presentation is to debunk the myth that analyzing the security of hardware is difficult. From the perspective of a software reverse engineer we present the process of studying a hardware-encrypted, PIN secured, external hard drive: the Zalman VE-400. While the end result of the analysis and attack is not a full success as it was not possible to recover an encrypted drive, it shows that the drive is nevertheless vulnerable by design. 1 Introduction 1.1 The target Analysing the security of hardware products seems to scare software reversers and hackers. It used to scare us. But, fortunately, today there is no need to know much about electronics, as most products are just System on Chip (SoC), a single integrated circuit with IO and a CPU or microcontroller. All that is needed is a bit of soldering ability, a multimeter, some useful pieces of hardware and a brain. The subject here is not embedded systems in the now common sense of “small hardware running Linux” but smaller systems using one or two chips. Most interesting for software hackers are encrypted HDD/USB keys: their functionnality is conceptually simple and they provide an interesting target. We will focus on the Zalman VE-400 encrypted drive, a consumer enclosure for 2.5" SATA hard drives which supports hardware encryption. It also supports advanced features like mounting ISO files as virtual optical drives. To do so, the user must choose between the ExFAT and NTFS filesystem support, by reflashing the correct firmware.
    [Show full text]
  • Nouveau Mode Opératoire Pour La Cryptographie *
    Nouveau Mode Opératoire pour la Cryptographie * Naima Hadj-Said*, Adda Ali-Pacha, Mohamed Sadek Ali-Pacha – Aek Haouas *Laboratoire SIMPA (Signal-Image-Parole) Université des Sciences et de la Technologie d’Oran USTO , BP 1505 El M’Naouer Oran 31036 Algerie [email protected] Résumé : Un mode opératoire consiste en la description détaillée des actions nécessaires à l'obtention d'un résultat. Il décrit généralement le déroulement détaillé des opérations effectuées sur un poste fixe, mais il peut également décrire l'enchaînement des opérations de poste à poste. Un mode opératoire décrivant les enchaînements opératoires de poste à poste permet de définir : -l'ensemble des postes de travail concernés par la réalisation d'un produit, d'une pièce élémentaire, - les temps de passage prévus (alloués) à chaque poste, -l'ordre logique d'intervention de chaque poste (machine, ou poste manuel), -les conditions d'enchaînement, de déclenchement, des opérations successives, -les moyens de transfert de poste à poste. En cryptographie, un mode d'opération est la manière de traiter les blocs de texte clairs et chiffrés au sein d'un algorithme de chiffrement par bloc ou bien c’est la présentation d’une méthode de chaînage des blocs dans un chiffrement par blocs. Plusieurs modes existent possédant leur propre atout, certains sont plus vulnérables que d'autres et certains modes combinent les concepts d'authentification et sécurité. Dans ce travail on essaie de faire la synthèse des modes opératoires des systèmes cryptographique et de proposer une bonne alternative pour faire le bon choix du vecteur d'initialisation de ces modes, avec la suggestion d’un nouveau mode opératoire qu’on a appelé : mode Autonome Secure blocK (ASK).
    [Show full text]
  • Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module V4.0
    Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module v4.0 FIPS 140-2 Non-Proprietary Security Policy Version 1.2 Last update: 2016-08-29 Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.co m ©2016 Red Hat Enterprise Linux / atsec information security corporation Page 1 of 24 This document can be reproduced and distributed only whole and intact, including this copyright notice. Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module v4.0 FIPS 140-2 Non-Proprietary Security Policy Table of Contents 1Cryptographic Module Specification........................................................................................4 1.1Module Overview...........................................................................................................4 1.2FIPS 140-2 validation.....................................................................................................6 1.3Modes of Operations......................................................................................................7 2Cryptographic Module Ports and Interfaces.............................................................................8 3Roles, Services and Authentication.........................................................................................9 3.1Roles.............................................................................................................................. 9 3.2Services........................................................................................................................
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • Enclave Security and Address-Based Side Channels
    Graz University of Technology Faculty of Computer Science Institute of Applied Information Processing and Communications IAIK Enclave Security and Address-based Side Channels Assessors: A PhD Thesis Presented to the Prof. Stefan Mangard Faculty of Computer Science in Prof. Thomas Eisenbarth Fulfillment of the Requirements for the PhD Degree by June 2020 Samuel Weiser Samuel Weiser Enclave Security and Address-based Side Channels DOCTORAL THESIS to achieve the university degree of Doctor of Technical Sciences; Dr. techn. submitted to Graz University of Technology Assessors Prof. Stefan Mangard Institute of Applied Information Processing and Communications Graz University of Technology Prof. Thomas Eisenbarth Institute for IT Security Universit¨atzu L¨ubeck Graz, June 2020 SSS AFFIDAVIT I declare that I have authored this thesis independently, that I have not used other than the declared sources/resources, and that I have explicitly indicated all material which has been quoted either literally or by content from the sources used. The text document uploaded to TUGRAZonline is identical to the present doctoral thesis. Date, Signature SSS Prologue Everyone has the right to life, liberty and security of person. Universal Declaration of Human Rights, Article 3 Our life turned digital, and so did we. Not long ago, the globalized commu- nication that we enjoy today on an everyday basis was the privilege of a few. Nowadays, artificial intelligence in the cloud, smartified handhelds, low-power Internet-of-Things gadgets, and self-maneuvering objects in the physical world are promising us unthinkable freedom in shaping our personal lives as well as society as a whole. Sadly, our collective excitement about the \new", the \better", the \more", the \instant", has overruled our sense of security and privacy.
    [Show full text]
  • Format Preserving Encryption
    – Figure 1: Cover picture Format Preserving Encryption Bachelor Thesis Degree programme: Bachelor of Science in Computer Science Author: Matthias Liechti, Rizja Schmid Thesis advisor: Prof. Dr. Reto Koenig Expert: Stefan Berner Date: 12.06.2015 Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences Management Summary This thesis aims to give a theoretical as well as practical overview of an emerging issue in the field of IT security named Format Preserving Encryption (FPE). Although FPE is not new, it is relatively unknown. It is used in the full-disk encryption and some other areas. Nevertheless, it is to this day even unknown to many cryptographers. Another issue that is on everyone's lips is the Internet of Things (IoT). IoT offers a whole new scope for FPE and could give it possibly a further boost. Format Preserving Encryption is - as the name says - an encryption in which the format of the encrypted data is maintained. When a plaintext is encrypted with FPE, the ciphertext then has the same format again. As illustrated for example on the cover page: If we encrypt the owner and the number of a credit card with AES we get an unrecognizable string. If we use FPE instead, we might get for example Paul Miller and the number 4000 0838 7507 2846. The advantage is that for man and/or machine nothing changes. The encryption is therefore not noticed without analysis of the data. The advantage can also become a disadvantage. An attacker has with the format of the ciphertext already information about the plaintext.
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 9,514,285 B2 Durham Et Al
    USO09514285B2 (12) United States Patent (10) Patent No.: US 9,514,285 B2 Durham et al. (45) Date of Patent: Dec. 6, 2016 (54) CREATING STACK POSITION DEPENDENT (56) References Cited CRYPTOGRAPHC RETURN ADDRESS TO MTGATE RETURN ORIENTED U.S. PATENT DOCUMENTS PROGRAMMING ATTACKS 7.853,803 B2 * 12/2010 Milliken ................. GO6F 21/52 713, 176 (71) Applicant: Intel Corporation, Santa Clara, CA 2014/0173293 A1* 6/2014 Kaplan ................... G06F 21.54 (US) T13, 190 (72) Inventors: David M. Durham, Beaverton, OR OTHER PUBLICATIONS (US); Baiju V. Patel, Portland, OR “Disk encryption theory,” available at http://en.wikipedia.org/wiki/ (US) XEX-TCB-CTS, accessed Dec. 29, 2014, 6 pages. “The Heartbleed bug, available at http://heartbleed.com/, accessed (73) Assignee: Intel Corporation, Santa Clara, CA Dec. 29, 2014, 7 pages. (US) “OpenSSL.” available at http://en.wikipedia.org/wiki/OpenSSL, accessed Dec. 29, 2014, 13 pages. (*) Notice: Subject to any disclaimer, the term of this “Return-oriented programming,' available at http://en.wikipedia. patent is extended or adjusted under 35 org/wiki/Return-oriented programming, accessed Dec. 29, 2014, 4 pageS. U.S.C. 154(b) by 0 days. “Buffer overflow,” available at http://en.wikipedia.org/wiki/Buf (21) Appl. No.: 14/498,521 fer overflow, accessed Dec. 29, 2014, 12 pages. (22) Filed: Sep. 26, 2014 * cited by examiner Primary Examiner — Jacob Lipman (65) Prior Publication Data (74) Attorney, Agent, or Firm — Barnes & Thornburg US 2016/0094.552 A1 Mar. 31, 2016 LLP (51) Int. C. (57) ABSTRACT G6F 2/54 (2013.01) A computing device includes technologies for securing G06F2L/00 (2013.01) return addresses that are used by a processor to control the (52) U.S.
    [Show full text]
  • I.MX Encrypted Storage Using CAAM Secure Keys Rev
    AN12714 i.MX Encrypted Storage Using CAAM Secure Keys Rev. 1 — 11/2020 Application Note Contents 1 Preface 1 Preface............................................1 Devices often contain highly sensitive information which is consistently at risk 1.1 Intended audience and scope......1 1.2 References...................................1 to get physically lost or stolen. Setting user passwords does not guarantee data 2 Overview......................................... 1 protection against unauthorized access. The attackers can simply bypass the 2.1 DM-Crypt......................................1 software system of a device and access the data storage directly. Only the 2.2 DM-Crypt accelerated by CAAM use of encryption can guarantee data confidentiality in the case where storage .....................................................2 media is directly accessed. 2.3 DM-Crypt using CAAM's Secure Key...............................................3 This document provides steps to run a transparent storage encryption at block 3 Hands-On........................................4 level using DM-Crypt taking advantage of the secure key feature provided 3.1 Installation....................................4 by i.MXs Cryptographic Accelerator and Assurance Module (CAAM). The 3.2 Usage...........................................6 document applies to all i.MX SoCs having CAAM module. The feature is not 3.3 Performance................................ 9 available on i.MX SoCs with DCP. 4 Revision History............................ 10 5 Appendix A. Configuration...........
    [Show full text]