DOCSLIB.ORG

Arxiv:1909.01785V2 [Cs.CR] 1 Apr 2020

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Arxiv:1909.01785V2 [Cs.CR] 1 Apr 2020 Certified Side Channels Cesar Pereida García1, Sohaib ul Hassan1, Nicola Tuveri1, Iaroslav Gridin1, Alejandro Cabrera Aldaya1,2, and Billy Bob Brumley1 1Tampere University, Tampere, Finland {cesar.pereidagarcia,n.sohaibulhassan,nicola.tuveri,iaroslav.gridin,billy.brumley}@tuni.fi 2Universidad Tecnológica de la Habana (CUJAE), Habana, Cuba [email protected] Abstract the multitude of standardized cryptographic key formats to choose from when persisting keys: which one to choose, and We demonstrate that the format in which private keys are per- does the choice matter? Surprisingly, it does—we demon- sisted impacts Side Channel Analysis (SCA) security. Survey- strate different key formats trigger different behavior within ing several widely deployed software libraries, we investigate software libraries, permeating all the way down to the low the formats they support, how they parse these keys, and what level arithmetic for the corresponding cryptographic primitive. runtime decisions they make. We uncover a combination of (ii) At the specification level, alongside required parameters, weaknesses and vulnerabilities, in extreme cases inducing standardized key formats often contain optional parameters: completely disjoint multi-precision arithmetic stacks deep does including or excluding optional parameters impact se- within the cryptosystem level for keys that otherwise seem curity? Surprisingly, it does. We demonstrate that omitting logically equivalent. Exploiting these vulnerabilities, we de- optional parameters can cause extremely different execution sign and implement key recovery attacks utilizing signals flows deep within a software library, and also that two keys ranging from electromagnetic (EM) emanations, to granular seemingly mathematically identical at the specification level microarchitecture cache timings, to coarse traditional wall can be treated by a software library as inequivalent, again clock timings. reaching very different arithmetic code deep within the li- brary. 1 Introduction Furthermore, we demonstrate that key parsing in general is a lucrative SCA attack vector. This is due mostly to software Academic SCA tends to focus on implementations of crypto- engineering constraints. Complex libraries inevitably stray to graphic primitives in isolation. With this view, the assumption convoluted data structures containing generous nesting levels is that any higher level protocol or system built upon imple- to meet the demands of broad standardized cryptography. This mentations of these primitives will naturally benefit from SCA is exacerbated by the natural urge to handle keys generically mitigations in place at lower levels. when faced with extremely diverse cryptographic standards Our work questions this assumption, and invalidates it with spanning RSA, DSA, ECDSA, Ed25519, Ed448, GOST, SM2, several concrete vulnerabilities and attacks against modern etc. primitives. The motivation behind this generalization is arXiv:1909.01785v2 [cs.CR] 1 Apr 2020 software libraries: we dub these Certified Side Channels, since to abstract away underlying cryptographic details from appli- the novel attack vector is deeply rooted in cryptography stan- cation developers linking against a library—more often than dards. For this vector, “certified” is in the certificate sense (e.g. not, these developers are not cryptography experts. Never- X.509), not in the Common Criteria sense. Counter-intuitively, theless, we observe that when loading keys modern security we demonstrate that the format in which keys are stored plays libraries make varying design choices that ultimately impact a significant role in real world SCA security. Detailed security SCA security. From the functionality perspective, these de- recommendations for key persistence are scarce; e.g. FIPS sign choices are sensible; from the security perspective, we 140-2 vaguely states “Cryptographic keys stored within a demonstrate they are often questionable. cryptographic module shall be stored either in plaintext form Outline. Section 2 gives an overview of the related back- or encrypted form [::] Documentation shall specify the key ground and previous work. Section 3 discusses the vulnerabil- storage methods employed by a cryptographic module”[1, ities discovered as a result of our analysis, with microarchitec- 4.7.5]. ture SCA evaluations on OpenSSL RSA, DSA, and mbedTLS There are (at least) two high level dimensions at play re- RSA. We also demonstrate end-to-end attacks on OpenSSL garding key formats as an SCA attack vector: (i) Among ECDSA using timing and EM side channels in Section 4. We 1 conclude in Section 5. decentralization is obtained delegating the authority on sub- trees to entities such as countries and organizations. This 2 Background mechanism solves the problem of assigning globally unique identifiers to entities to facilitate global communication. 2.1 Public Key Cryptography RSA private keys. PKCS #1 (RFC 8017[ 55]) also defines the ASN.1 DER encoding for an RSA private key, defining an ECDSA. Denote an order-n generator G 2 E of an elliptic item for each of its eight parameters. As further discussed in curve group E with cardinality f n and n a large prime and Section 3.4, the standard does not strictly require implemen- f the small cofactor. The user’s private key a is an integer tations to include all the eight parameters during serialization, uniformly chosen from f1::n − 1g and the corresponding nor to invalidate the object during deserialization if one of the public key is D = [a]G. With approved hash function Hash(), parameters is not included. the ECDSA digital signature (r;s) on message m (denoting EC private keys. The ANSI X9.62 standard [51] is the nor- with h < n the representation of Hash(m) as an integer) is mative reference for the definition of the ECDSA cryptosys- −1 r = ([k]G)x mod n; s = k (h + ar) mod n (1) tem and the encoding of ECDSA public keys, but omits a serialization for private keys. The SEC1 standard [2] follows where k is a nonce chosen uniformly from f1::n − 1g. ANSI X9.62 for the public key ASN.1 and provides a DER RSA. According to the PKCS #1 v2.2 standard (RFC encoding also for EC private keys, but allows generous vari- 8017[ 55]), an RSA private key consists of the eight param- ation as it seems to assume different encapsulating options eters fN;e; p;q;d;dp;dq;iqg where all but the first two are depending on different protocols in which the EC private secret, and N = pq for primes p, q. Public exponent e is usu- key can be used. Flexibility in the format brings complexity ally small and the following holds: in the deserializer implementation, that needs to be stateful w.r.t. parsing of the container of the private key encoding and d = e−1 mod lcm(p − 1;q − 1) (2) flexible enough to interoperate with other implementations and interpretations of the standards: this already suggests In addition, Chinese Remainder Theorem (CRT) parameters that the parsing stage shows potential as a lucrative SCA at- are stored for speeding up RSA computations: tack vector. The SEC1 ASN.1 notation for ECPrivateKey contains the private scalar as an octet string, an optional (de- d = d mod p; d = d mod q; i = q−1 mod p (3) p q q pending on the container) ECDomainParameters field, and an optional bit string field to include the public part of the 2.2 Key Formats key pair. The ECDomainParameters can be null, if the curve parameters are specified in the container encapsulating the Interoperability among different software and hardware plat- ECPrivateKey, or contain either an OID for a “named” curve, forms in handling keys and other cryptographic objects re- or a SpecifiedECDomain structure. The latter, simplifying, quires common standards to serialize and deserialize such contains a description of the field over which the EC group objects. ASN.1 or Abstract Syntax Notation One is an in- is defined, the definition of the curve equation in terms of terface description language to define data structures and the coefficients of its Short Weierstrass form, an encoding their (de/)serialization, standardized [69] jointly by ITU-T of the EC base point, and its order n. Finally it can option- and ISO/IEC since 1984 and widely adopted. It supports ally contain a component to represent a small cofactor f as several encoding rules, among which the Distinguished En- defined at the beginning of this section. In Section 3.1 we coding Rules (DER), a binary format ensuring uniqueness and will further discuss about the security consequences caused concision, has been preferred for the representation of crypto- in actual implementations by the logic required to support the graphic objects. PEM (RFC 7468[45]) is a textual file format cofactor as an optional field. to store and trasmit cryptographic objects, widespread despite being originally developed as part of the now obsoleted IETF MSBLOB key format. MSBLOB is the OpenSSL implemen- 1 standards for Privacy-Enhanced Mail after which it is named. tation of Microsoft’s private key BLOB format supporting PEM uses base64 to encode the binary DER serialization of different cryptosystems, using custom defined structures and an object, providing some degree of human readability and fields. DSS key BLOB uses an arbitrary structure, while RSA support for text-based protocols like e-mail and HTTP(S). key BLOBs follows PKCS #1 with minor differences. To iden- tify each cryptosystem, a “magic member” is used in the key Object Identifiers. The ASN.1 syntax also defines an BLOB structure—the member is the hexadecimal represen- OBJECT IDENTIFIER primitive type which represents a glob- tation of the ASCII encoding of the cryptosystem name, e.g. ally unique identifier for an object. ITU-T and ISO jointly “RSA1”, “RSA2”, “DSS1”, “DSS2”, etc., where the integer manage a decentralized hierarchical registry of object iden- tifiers or OID s. The registry is organized as a tree structure, 1https://docs.microsoft.com/en-us/windows/win32/ where every node is authoritative for its descendants, and seccrypto/base-provider-key-blobs 2 dictates if it is a public or a private key.
Load more

Recommended publications
  • A Focus on S/MIME
    The University of Saskatchewan Department of Computer Science Technical Report #2011-03 Cryptographic Security for Emails: A Focus on S/MIME Minhaz Fahim Zibran Department of Computer Science University of Saskatchewan Email: [email protected] Abstract In this paper I present a study on \S/MIME", which has become the industry standard for secure email exchange. Based on existing literature review, the study examines S/MIME in depth with specific emphasis on its architecture, strengths, and deficiencies. The study also identifies usability issues related to S/MIME enabled email clients, which indicate scopes for further improvements in those implementations. Obstacles in the adoption of S/MIME are also identified indicating what is required for its successful adoption in the community. In presenting the study, the paper contributes in two ways: (a) for any newcomer in the field of cryptography this paper will be a useful resource to quickly learn about S/MIME in a fair level of detail, (b) the indication about limitations of S/MIME and its implementations reveals an avenue for further research in the area of email security, which may result in improvement of S/MIME itself, or its implementations in the email clients. Keywords: Email Security, S/MIME, MIME, PGP, PKI, Certificate, Email Authentication, Email Encryption, Key Management 1 Introduction Email has been a very common medium of communication these days. It somewhat re- places the traditional surface mail and many of the traditional ways of communication [32]. Today people send and read emails from their personal computers, business workstation, PDAs and even cell phones.
    [Show full text]
  • Towards a Hybrid Public Key Infrastructure (PKI): a Review
    Towards a Hybrid Public Key Infrastructure (PKI): A Review Priyadarshi Singh, Abdul Basit, N Chaitanya Kumar, and V. Ch. Venkaiah School of Computer and Information Sciences, University of Hyderabad, Hyderabad-500046, India Abstract. Traditional Certificate- based public key infrastructure (PKI) suffers from the problem of certificate overhead like its storage, verification, revocation etc. To overcome these problems, idea of certificate less identity-based public key cryptography (ID-PKC) was proposed by Shamir. This is suitable for closed trusted group only. Also, this concept has some inherent problems like key escrow problem, secure key channel problem, identity management overhead etc. Later on, there had been several works which tried to combine both the cryptographic techniques such that the resulting hybrid PKI framework is built upon the best features of both the cryptographic techniques. It had been shown that this approach solves many problems associated with an individual cryptosystem. In this paper, we have reviewed and compared such hybrid schemes which tried to combine both the certificate based PKC and ID-based PKC. Also, the summary of the comparison, based on various features, is presented in a table. Keywords: Certificate-based PKI; Identity-based public key cryptography (ID-PKC); Hybrid PKI 1 INTRODUCTION Public key infrastructure (PKI) and public key cryptography (PKC) [12] plays a vital role with four major components of digital security: authentication, integrity, confidentiality and non-repudiation. Infact, PKI enables the use of PKC through key management. The ”efficient and secure management of the key pairs during their whole life cycle" is the purpose of PKI, which involves key generation, key distribution, key renewal, key revocation etc [11].
    [Show full text]
  • Security Target Document
    Security Target Document Passport Certificate Server Ver. 4.1.1 Prepared for: Common Criteria EAL2 (augmented) 30 April 2002 2225 Sheppard Ave, Suite 1700 Toronto, Ontario, Canada M2J 5C2 TEL: 416-756-2324 FAX: 416-756-7346 [email protected] www.dvnet.com Passport Certificate Server V.4.1.1 Security Target 30 April 2002 Common Criteria EAL 2 (augmented) Version 1.00 TABLE OF CONTENTS 1 Introduction ............................................................................................................................................ 1 1.1 Security Target Identification......................................................................................................... 1 1.2 Security Target Overview............................................................................................................... 1 1.3 Common Criteria Conformance .....................................................................................................1 2 TOE Description..................................................................................................................................... 2 2.1 Product Deployment....................................................................................................................... 2 2.2 Product Functions........................................................................................................................... 2 2.3 Product Description ........................................................................................................................ 3 2.3.1 Platform
    [Show full text]
  • A Practical Evaluation of a High-Security Energy-Efficient
    sensors Article A Practical Evaluation of a High-Security Energy-Efficient Gateway for IoT Fog Computing Applications Manuel Suárez-Albela * , Tiago M. Fernández-Caramés , Paula Fraga-Lamas and Luis Castedo Department Computer Engineering, Faculty of Computer Science, Universidade da Coruña, 15071 A Coruña, Spain; [email protected] (T.M.F.-C.); [email protected] (P.F.-L.); [email protected] (L.C.) * Correspondence: [email protected]; Tel.: +34-981-167-000 (ext. 6051) Received: 28 July 2017; Accepted: 19 August 2017; Published: 29 August 2017 Abstract: Fog computing extends cloud computing to the edge of a network enabling new Internet of Things (IoT) applications and services, which may involve critical data that require privacy and security. In an IoT fog computing system, three elements can be distinguished: IoT nodes that collect data, the cloud, and interconnected IoT gateways that exchange messages with the IoT nodes and with the cloud. This article focuses on securing IoT gateways, which are assumed to be constrained in terms of computational resources, but that are able to offload some processing from the cloud and to reduce the latency in the responses to the IoT nodes. However, it is usually taken for granted that IoT gateways have direct access to the electrical grid, which is not always the case: in mission-critical applications like natural disaster relief or environmental monitoring, it is common to deploy IoT nodes and gateways in large areas where electricity comes from solar or wind energy that charge the batteries that power every device. In this article, how to secure IoT gateway communications while minimizing power consumption is analyzed.
    [Show full text]
  • Security Policies for the Federal Public Key Infrastructure
    Security Policies for the Federal Public Key Infrastructure Noel A. Nazario Security Technology Group National Institute of Standards and Technology Abstract This document discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI). Federal PKI policies deal with the generation, deactivation, and dissemination of public key certificates, the integrity of the infrastructure, maintenance of records, identification of certificate holders, and the establishment of trust relationships between Certification Authorities (CAs). The verification of a digital signature is not sufficient indication of the trustworthiness of an electronic message or data file. The verifier needs to factor the trustworthiness of the CAs involved in the certification of the sender. To accomplish this, the verifier needs to examine the certificate policy for those CAs. The Federal PKI Technical Security Policy establishes guidelines for the operation of Federal CAs and the identification of the parties requesting certification. It also defines Policy Approving Authorities (PAA) responsible for assessing the policies and operational practices of all Federal CAs within a domain and assigning them corresponding Federal Assurance Levels. These assurance levels may be used in lieu of a certificate policy when making an on-line determination of the trustworthiness of a certificate. Key words Certificate policy, Federal Assurance Levels, PAA, PKI, Policy Approving Authority, public key infrastructure, security policy. SECURITY POLICIES FOR THE FEDERAL PUBLIC KEY INFRASTRUCTURE Noel A. Nazario NIST North, Room 426 820 West Diamond Avenue Gaithersburg, MD 20899 [email protected] Introduction and Background This paper discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI).
    [Show full text]
  • Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D
    Main Points • Applying last week’s lectures in practice • Creating Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D. Joseph – VPN: Virtual Private Network September 26, 2005 September 26, 2005 CS161 Fall 2005 2 Joseph/Tygar/Vazirani/Wagner What is a Secure Channel? Plaintext Plaintext Creating Secure Channels Encryption / Internet Encryption / • Authentication and Data Integrity Decryption Decryption Ciphertext and MAC – Use Public Key Infrastructure or third-party server to authenticate each end to the other • A stream with these security requirements: – Add Message Authentication Code for – Authentication integrity • Ensures sender and receiver are who they claim to be – Confidentiality • Confidentiality • Ensures that data is read only by authorized users – Data integrity – Exchange session key for encrypt/decrypt ops • Ensures that data is not changed from source to destination • Bulk data transfer – Non-repudiation (not discussed today) • Ensures that sender can’t deny message and rcvr can’t deny msg • Key Distribution and Segmentation September 26, 2005 CS161 Fall 2005 3 September 26, 2005 CS161 Fall 2005 4 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Symmetric Key-based Symmetric Key-based Secure Channel Secure Channel Alice Bob • Sender (A) and receiver (B) share secret keys KABencrypt KABencrypt – One key for A è B confidentiality KABauth KABauth – One for A è B authentication/integrity Message MAC Compare? Message – Each message
    [Show full text]
  • The Most Dangerous Code in the World: Validating SSL Certificates In
    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
    [Show full text]
  • Practical Issues with TLS Client Certificate Authentication
    Practical Issues with TLS Client Certificate Authentication Arnis Parsovs Software Technology and Applications Competence Center, Estonia University of Tartu, Estonia [email protected] Abstract—The most widely used secure Internet communication Active security research is being conducted to improve standard TLS (Transport Layer Security) has an optional client password security, educate users on how to resist phishing certificate authentication feature that in theory has significant attacks, and to fix CA trust issues [1], [2]. However, the attacks security advantages over HTML form-based password authenti- mentioned above can be prevented or their impact can be cation. In this paper we discuss practical security and usability greatly reduced by using TLS client certificate authentication issues related to TLS client certificate authentication stemming (CCA), since the TLS CCA on the TLS protocol level protects from the server-side and browser implementations. In particular, we analyze Apache’s mod_ssl implementation on the server the client’s account on a legitimate server from a MITM side and the most popular browsers – Mozilla Firefox, Google attacker even in the case of a very powerful attacker who has Chrome and Microsoft Internet Explorer on the client side. We obtained a valid certificate signed by a trusted CA and who complement our paper with a measurement study performed in thus is able to impersonate the legitimate server. We believe Estonia where TLS client certificate authentication is widely used. that TLS CCA has great potential for improving Internet We present our recommendations to improve the security and security, and therefore in this paper we discuss current issues usability of TLS client certificate authentication.
    [Show full text]
  • Introduction to Public Key Technology and Federal PKI Infrastructure
    Withdrawn NIST Technical Series Publication Warning Notice The attached publication has been withdrawn (archived), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Withdrawn Publication Series/Number NIST Special Publication 800-32 Title Introduction to Public Key Technology and the Federal PKI Infrastructure Publication Date(s) February 26, 2001 Withdrawal Date September 13, 2021 Withdrawal Note SP 800-32 is withdrawn in its entirety. Superseding Publication(s) (if applicable) The attached publication has been superseded by the following publication(s): Series/Number Title Author(s) Publication Date(s) URL/DOI Additional Information (if applicable) Contact Computer Security Division (Information Technology Laboratory) Latest revision of the N/A attached publication Related Information https://csrc.nist.gov/projects/crypto-publication-review-project https://csrc.nist.gov/publications/detail/sp/800-32/archive/2001-02-26 Withdrawal https://csrc.nist.gov/news/2021/withdrawal-of-nist-special-pubs-800-15-25- Announcement Link and-32 Date updated: September 13, 2021 SP 800-32 IIInnntttrrroooddduuuccctttiiiooonnn tttooo PPPuuubbbllliiiccc KKKeeeyyy TTTeeeccchhhnnnooolllooogggyyy aaannnddd ttthhheee FFFeeedddeeerrraaalll PPPKKKIII IIInnnfffrrraaassstttrrruuuccctttuuurrreee D. Richard Kuhn Vincent C. Hu 26 February 2001 W. Timothy Polk Shu-Jen Chang 1 National Institute of Standards and Technology, 2001. U.S. Government publication. Not subject to copyright. Portions of this document have been abstracted from other U.S. Government publications, including: “Minimum Interoperability Specification for PKI Components (MISPC), Version 1” NIST SP 800-15, January 1998; “Certification Authority Systems”, OCC 99-20, Office of the Comptroller of the Currency, May 4, 1999; “Guideline for Implementing Cryptography in the Federal Government”, NIST SP800-21, November 1999; Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology, U.S.
    [Show full text]
  • A Security Framework for the Internet of Things in the Future Internet Architecture
    Article A Security Framework for the Internet of Things in the Future Internet Architecture Xiruo Liu 1, Meiyuan Zhao 2, Sugang Li 3, Feixiong Zhang 3 and Wade Trappe 3,* 1 Intel Labs, Hillsboro, OR 97124, USA; [email protected] 2 Google, Mountain View, CA 94043, USA; [email protected] 3 Department of Electrical and Computer Engineering, Rutgers University, Piscataway, NJ 08854, USA; [email protected] (S.L.); [email protected] (F.Z.) * Correspondence: [email protected]; Tel.: +1-848-932-0909 Academic Editors: Georgios Kambourakis and Constantinos Kolias Received: 5 June 2017; Accepted: 25 June 2017; Published: 28 June 2017 Abstract: The Internet of Things (IoT) is a recent trend that extends the boundary of the Internet to include a wide variety of computing devices. Connecting many stand-alone IoT systems through the Internet introduces many challenges, with security being front-and-center since much of the collected information will be exposed to a wide and often unknown audience. Unfortunately, due to the intrinsic capability limits of low-end IoT devices, which account for a majority of the IoT end hosts, many traditional security methods cannot be applied to secure IoT systems, which open a door for attacks and exploits directed both against IoT services and the broader Internet. This paper addresses this issue by introducing a unified IoT framework based on the MobilityFirst future Internet architecture that explicitly focuses on supporting security for the IoT. Our design integrates local IoT systems into the global Internet without losing usability, interoperability and security protection. Specifically, we introduced an IoT middleware layer that connects heterogeneous hardware in local IoT systems to the global MobilityFirst network.
    [Show full text]
  • Bivio 6310-NC Common Criteria Administrative Guidance
    Bivio 6310-NC Common Criteria Administrative Guidance Version 1.10 Nov 23, 2020 Bivio 6310-NC Common Criteria Administrative Guidance CONTENTS 1. Introduction .......................................................................................................................................... 5 2. Operational Environment – IT Requirements ....................................................................................... 6 3. Operational Environment – Procedural/Policy Requirements ............................................................. 7 4. Installation and Initial Configuration .................................................................................................... 7 Initial configuration ............................................................................................................................................... 8 Logging in and out of the system ........................................................................................................................ 10 Setting time ......................................................................................................................................................... 10 Enabling the NTP Client for Time Synchronization ............................................................................................. 11 Rebooting the system ......................................................................................................................................... 12 Power cycling the system ...................................................................................................................................
    [Show full text]
  • Designing a Secure, High-Performance Remote Attestation Protocol Alexander David Titus Worcester Polytechnic Institute
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by DigitalCommons@WPI Worcester Polytechnic Institute Digital WPI Major Qualifying Projects (All Years) Major Qualifying Projects October 2016 Trusted Execution Development: Designing a Secure, High-Performance Remote Attestation Protocol Alexander David Titus Worcester Polytechnic Institute Seth Daniel Norton Worcester Polytechnic Institute Follow this and additional works at: https://digitalcommons.wpi.edu/mqp-all Repository Citation Titus, A. D., & Norton, S. D. (2016). Trusted Execution Development: Designing a Secure, High-Performance Remote Attestation Protocol. Retrieved from https://digitalcommons.wpi.edu/mqp-all/1145 This Unrestricted is brought to you for free and open access by the Major Qualifying Projects at Digital WPI. It has been accepted for inclusion in Major Qualifying Projects (All Years) by an authorized administrator of Digital WPI. For more information, please contact [email protected]. Trusted Execution Development Designing a Secure, High-Performance Remote Attestation Protocol October 13, 2016 Written by Seth Norton Alex Titus Project Sponsored by the MITRE Corporation Project Faculty Advisor - Craig Shue Project Sponsor Advisor - Joshua Guttman Project Sponsor Advisor - John Ramsdell Abstract Intel Software Guard Extensions (SGX) are a Trusted Execution Environment (TEE) technology that allow programs to protect execution process and data from other processes on the platform. We propose a method to combine SGX attestation with Transport Layer Security (TLS). Doing so will combine guarantees about the program, runtime environment, and machine identity into a normal TLS handshake. We implemented a basic server using SGX/TLS and provide performance details and lessons learned during development.
    [Show full text]