DOCSLIB.ORG

This Document Includes Text Contributed by Nikos Mavrogiannopoulos, Simon Josefsson, Daiki Ueno, Carolin Latze, Alfredo Pironti, Ted Zlatanov and Andrew Mcdonald

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
This Document Includes Text Contributed by Nikos Mavrogiannopoulos, Simon Josefsson, Daiki Ueno, Carolin Latze, Alfredo Pironti, Ted Zlatanov and Andrew Mcdonald This document includes text contributed by Nikos Mavrogiannopoulos, Simon Josefsson, Daiki Ueno, Carolin Latze, Alfredo Pironti, Ted Zlatanov and Andrew McDonald. Several corrections are due to Patrick Pelletier and Andreas Metzler. ISBN 978-1-326-00266-4 Copyright c 2001-2015 Free Software Foundation, Inc. Copyright c 2001-2015 Nikos Mavrogiannopoulos Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". Contents Preface xiii 1. Introduction to GnuTLS1 1.1. Downloading and installing.............................1 1.2. Installing for a software distribution........................2 1.3. Overview.......................................3 2. Introduction to TLS and DTLS5 2.1. TLS Layers......................................5 2.2. The Transport Layer.................................5 2.3. The TLS record protocol...............................6 2.3.1. Encryption algorithms used in the record layer..............6 2.3.2. Compression algorithms used in the record layer.............8 2.3.3. Weaknesses and countermeasures......................8 2.3.4. On record padding..............................9 2.4. The TLS alert protocol...............................9 2.5. The TLS handshake protocol............................ 10 2.5.1. TLS ciphersuites............................... 11 2.5.2. Authentication................................ 11 2.5.3. Client authentication............................. 11 2.5.4. Resuming sessions.............................. 11 2.6. TLS extensions.................................... 12 2.6.1. Maximum fragment length negotiation................... 12 2.6.2. Server name indication............................ 12 2.6.3. Session tickets................................ 13 2.6.4. HeartBeat................................... 13 2.6.5. Safe renegotiation.............................. 14 2.6.6. OCSP status request............................. 15 2.6.7. SRTP..................................... 16 2.6.8. Application Layer Protocol Negotiation (ALPN)............. 17 2.6.9. Extensions and Supplemental Data..................... 18 2.7. How to use TLS in application protocols...................... 18 2.7.1. Separate ports................................ 18 2.7.2. Upward negotiation............................. 18 2.8. On SSL 2 and older protocols............................ 20 3. Authentication methods 21 3.1. Certificate authentication.............................. 21 3.1.1. X.509 certificates............................... 21 3.1.2. OpenPGP certificates............................ 36 3.1.3. Advanced certificate verification...................... 38 3.1.4. Digital signatures............................... 39 iii Contents 3.2. More on certificate authentication......................... 41 3.2.1. PKCS #10 certificate requests....................... 41 3.2.2. PKIX certificate revocation lists...................... 44 3.2.3. OCSP certificate status checking...................... 47 3.2.4. Managing encrypted keys.......................... 51 3.2.5. Invoking certtool............................... 55 3.2.6. Invoking ocsptool............................... 72 3.2.7. Invoking danetool.............................. 76 3.3. Shared-key and anonymous authentication..................... 82 3.3.1. SRP authentication............................. 82 3.3.2. PSK authentication............................. 86 3.3.3. Anonymous authentication......................... 88 3.4. Selecting an appropriate authentication method.................. 88 3.4.1. Two peers with an out-of-band channel.................. 88 3.4.2. Two peers without an out-of-band channel................ 89 3.4.3. Two peers and a trusted third party.................... 89 4. Abstract keys types and Hardware security modules 97 4.1. Abstract key types.................................. 97 4.1.1. Public keys.................................. 98 4.1.2. Private keys.................................. 100 4.1.3. Operations.................................. 102 4.2. System and application-specific keys........................ 105 4.2.1. System-specific keys............................. 105 4.2.2. Application-specific keys........................... 105 4.3. Smart cards and HSMs................................ 107 4.3.1. Initialization................................. 107 4.3.2. Accessing objects that require a PIN.................... 109 4.3.3. Reading objects................................ 110 4.3.4. Writing objects................................ 113 4.3.5. Using a PKCS #11 token with TLS.................... 114 4.3.6. Invoking p11tool............................... 114 4.3.7. p11tool help/usage (\--help")....................... 115 4.3.8. token-related-options options........................ 117 4.3.9. object-list-related-options options...................... 117 4.3.10. keygen-related-options options....................... 118 4.3.11. write-object-related-options options.................... 119 4.3.12. other-options options............................. 121 4.3.13. p11tool exit status.............................. 123 4.3.14. p11tool See Also............................... 123 4.3.15. p11tool Examples.............................. 123 4.4. Trusted Platform Module (TPM).......................... 124 4.4.1. Keys in TPM................................. 124 4.4.2. Key generation................................ 125 4.4.3. Using keys.................................. 126 4.4.4. Invoking tpmtool............................... 127 iv Contents 4.4.5. tpmtool help/usage (\--help")....................... 128 4.4.6. debug option (-d)............................... 129 4.4.7. generate-rsa option.............................. 129 4.4.8. user option.................................. 129 4.4.9. system option................................. 129 4.4.10. test-sign option................................ 130 4.4.11. sec-param option............................... 130 4.4.12. inder option.................................. 130 4.4.13. outder option................................. 130 4.4.14. tpmtool exit status.............................. 130 4.4.15. tpmtool See Also............................... 130 4.4.16. tpmtool Examples.............................. 131 5. How to use GnuTLS in applications 133 5.1. Introduction...................................... 133 5.1.1. General idea................................. 133 5.1.2. Error handling................................ 134 5.1.3. Common types................................ 135 5.1.4. Debugging and auditing........................... 135 5.1.5. Thread safety................................. 136 5.1.6. Running in a sandbox............................ 137 5.1.7. Sessions and fork............................... 138 5.1.8. Callback functions.............................. 138 5.2. Preparation...................................... 139 5.2.1. Headers.................................... 139 5.2.2. Initialization................................. 139 5.2.3. Version check................................. 139 5.2.4. Building the source.............................. 140 5.3. Session initialization................................. 140 5.4. Associating the credentials.............................. 142 5.4.1. Certificates.................................. 142 5.4.2. SRP...................................... 147 5.4.3. PSK...................................... 149 5.4.4. Anonymous.................................. 150 5.5. Setting up the transport layer............................ 151 5.5.1. Asynchronous operation........................... 154 5.5.2. DTLS sessions................................ 155 5.6. TLS handshake.................................... 156 5.7. Data transfer and termination............................ 158 5.8. Buffered data transfer................................ 161 5.9. Handling alerts.................................... 161 5.10. Priority strings.................................... 163 5.11. Selecting cryptographic key sizes.......................... 168 5.12. Advanced topics................................... 170 5.12.1. Session resumption.............................. 170 5.12.2. Certificate verification............................ 172 v Contents 5.12.3. Re-authentication.............................. 175 5.12.4. Parameter generation............................ 177 5.12.5. Deriving keys for other applications/protocols............... 178 5.12.6. Channel bindings............................... 178 5.12.7. Interoperability................................ 179 5.12.8. Compatibility with the OpenSSL library.................. 179 6. GnuTLS application examples 181 6.1. Client examples.................................... 181 6.1.1. Simple client example with X.509 certificate support........... 181 6.1.2. Simple client example with SSH-style certificate verification....... 184 6.1.3. Simple client example with anonymous authentication.......... 186 6.1.4. Simple datagram TLS client example.................... 188 6.1.5. Obtaining session information........................ 191 6.1.6. Using a callback to select the certificate to use.............. 193 6.1.7. Verifying a certificate............................ 198 6.1.8. Using a smart card with TLS........................ 200 6.1.9. Client with resume capability example................... 203 6.1.10. Simple client
Load more

Recommended publications
  • Rigorous Cache Side Channel Mitigation Via Selective Circuit Compilation
    RiCaSi: Rigorous Cache Side Channel Mitigation via Selective Circuit Compilation B Heiko Mantel, Lukas Scheidel, Thomas Schneider, Alexandra Weber( ), Christian Weinert, and Tim Weißmantel Technical University of Darmstadt, Darmstadt, Germany {mantel,weber,weissmantel}@mais.informatik.tu-darmstadt.de, {scheidel,schneider,weinert}@encrypto.cs.tu-darmstadt.de Abstract. Cache side channels constitute a persistent threat to crypto implementations. In particular, block ciphers are prone to attacks when implemented with a simple lookup-table approach. Implementing crypto as software evaluations of circuits avoids this threat but is very costly. We propose an approach that combines program analysis and circuit compilation to support the selective hardening of regular C implemen- tations against cache side channels. We implement this approach in our toolchain RiCaSi. RiCaSi avoids unnecessary complexity and overhead if it can derive sufficiently strong security guarantees for the original implementation. If necessary, RiCaSi produces a circuit-based, hardened implementation. For this, it leverages established circuit-compilation technology from the area of secure computation. A final program analysis step ensures that the hardening is, indeed, effective. 1 Introduction Cache side channels are unintended communication channels of programs. Cache- side-channel leakage might occur if a program accesses memory addresses that depend on secret information like cryptographic keys. When these secret-depen- dent memory addresses are loaded into a shared cache, an attacker might deduce the secret information based on observing the cache. Such cache side channels are particularly dangerous for implementations of block ciphers, as shown, e.g., by attacks on implementations of DES [58,67], AES [2,11,57], and Camellia [59,67,73].
    [Show full text]
  • Siderand: a Heuristic and Prototype of a Side-Channel-Based Cryptographically Secure Random Seeder Designed to Be Platform- and Architecture-Agnostic
    SideRand: A Heuristic and Prototype of a Side-Channel-Based Cryptographically Secure Random Seeder Designed to Be Platform- and Architecture-Agnostic JV ROIG, Advanced Research Center – Asia Pacific College Generating secure random numbers is vital to the security and privacy infrastructures we rely on today. Having a computer system generate a secure random number is not a trivial problem due to the deterministic nature of computer systems. Servers commonly deal with this problem through hardware-based random number generators, which can come in the form of expansion cards, dongles, or integrated into the CPU itself. With the explosion of network- and internet-connected devices, however, the problem of cryptography is no longer a server-centric problem; even small devices need a reliable source of randomness for cryptographic operations – for example, network devices and appliances like routers, switches and access points, as well as various Internet-of-Things (IoT) devices for security and remote management. This paper proposes a software solution based on side-channel measurements as a source of high- quality entropy (nicknamed “SideRand”), that can theoretically be applied to most platforms (large servers, appliances, even maker boards like RaspberryPi or Arduino), and generates a seed for a regular CSPRNG to enable proper cryptographic operations for security and privacy. This paper also proposes two criteria – openness and auditability – as essential requirements for confidence in any random generator for cryptographic use, and discusses how SideRand meets the two criteria (and how most hardware devices do not). CCS Concepts: • Security and privacy → Cryptography KEYWORDS Cryptographically secure random number generation; side-channel based CSPRNG 1 INTRODUCTION 1.1 Generating Random Numbers for Privacy and Security The ability to generate strong random numbers is essential to cryptography, and central to security and privacy in the IT world.
    [Show full text]
  • Cryptoprocessing on the Arduino
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by NORA - Norwegian Open Research Archives Cryptoprocessing on the Arduino Protecting user data using affordable microcontroller development kits Stig Tore Johannesen Master of Science in Informatics Submission date: August 2014 Supervisor: Guttorm Sindre, IDI Co-supervisor: Danilo Gligoroski, ITEM Norwegian University of Science and Technology Department of Computer and Information Science Acknowledgements I would like to thank my thesis advisor, Guttorm Sindre, for all his help during the writing process. I would also like to thank my co-advisor, Danilo Gligoroski, for getting me started on the technical aspect of the report. Thanks are also owed to everyone who helped me by reading through and commenting on the structure and language of this report. i ii Abstract There is a growing trend of data breaches, which this report looks into. The breaches often turn out to have, at their core, an element of either poor security management, or outdated or incorrectly applied security procedures. With this in mind, an affordable off-the-shelf microcontroller development kit is suggested as a way to lessen the impact of data theft during data breaches. Utilising an Arduino Due this report looks at the performance avail- able for cryptoprocessing and key storage, showing that while it is not a viable solution for encrypting large amounts of data, it is however suitable for securely encrypting limited data sets, such as customer data. iii iv Table of Contents 1 Introduction3 1.1 Goal.....................................4 2 Research Methods5 2.1 Possible Methodologies...........................5 2.2 Research Question 1............................6 2.3 Research Question 2............................6 2.4 Research Question 3............................7 2.5 Research Question 4............................7 3 Background9 3.1 Breaches...................................9 3.1.1 Sony Online Entertainment, 2011.................9 3.1.2 LinkedIn, 2012..........................
    [Show full text]
  • Architecture of VIA Isaiah (NANO)
    Architecture of VIA Isaiah (NANO) Jan Davidek dav053 2008/2009 1. Introduction to the VIA Nano™ Processor The last few years have seen significant changes within the microprocessor industry, and indeed the entire IT landscape. Much of this change has been driven by three factors: the increasing focus of both business and consumer on energy efficiency, the rise of mobile computing, and the growing performance requirements of computing devices in a fast expanding multimedia environment. In the microprocessor space, the traditional race for ever faster processing speeds has given way to one that factors in the energy used to achieve those speeds. Performance per watt is the new metric by which quality is measured, with all the major players endeavoring to increase the performance capabilities of their products, while reducing the amount of energy that they require. Based on the recently announced VIA Isaiah Architecture, the new VIA Nano™ processor is a next-generation x86 processor that sets the standard in power efficiency for tomorrow’s immersive internet experience. With advanced power and thermal management features helping to make it the world’s most energy efficient x86 processor architecture, the VIA Nano processor also boasts ultra modern functionality, high-performance computation and media processing, and enhanced VIA PadLock™ hardware security features. Augmenting the VIA C7® family of processors, the VIA Nano processor’s pin compatibility extends the VIA processor platform portfolio, enabling OEMs to offer a wider range of products for different market segments, and furnishing them with the ability to upgrade device performance without incurring the time and cost expense associated with system redesign.
    [Show full text]
  • An Implementation of AES Algorithm on Multicore Processors for High Throughput
    บทความวจิ ยั –วชาการิ การประชุมวชาการิ งานวิจยั และพฒนาเชั ิงประยกตุ ์ คร้ังที่ 6 การพฒนาเทคโนโลยั เพี ื่อให้โลกมีสนตั ิสุข ECTI-CARD Proceedings 2014, Chiang Mai, Thailand An implementation of AES algorithm on multicore processors for high throughput Supachai Thongsuk1, Prabhas Chongstitvatana, Ph.D. 2 Department of Computer Engineering Faculty of Engineering, Chulalongkorn University Bangkok, Thailand E-mail: [email protected], [email protected] Abstract Block of data input is 128 bits or 4 words in 4x4 square matrix of AES (Advanced Encryption Standard) algorithm is a block bytes. The 4x4 matrix of bytes is called the state. The number of encryption algorithm established by the U.S. National Institute of iterations depends on the key length. (Table 1) Standards and Technology (NIST) in 2001. It has been adopted by many AES steps data security systems and now used worldwide. Most of AES 1) Key expansion -- Round keys are derived from the cipher key. Each implementations are for single-core processors. To achieve high round requires a separate key block. performance for large data, this work proposed an AES algorithm for multi-core processors. Using parallelism inherent in large data, all 2) Initial round -- Each byte of the state is bitwise XOR with the round cores are working concurrently to speed up the task. key. Keywords: cryptography; AES; Multicore processor; 3) Rounds -- A round consisted of four transformations: SubBytes, ShiftRows, MixColumns, AddRoundKey. 1. Introduction The information security has become an important concern today 4) Final round -- Three transformations: SubBytes, ShiftRows, due to popular use of computers. The AES algorithm is a standard AddRoundKey.
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 8,654,970 B2 Olson Et Al
    USOO8654970B2 (12) United States Patent (10) Patent No.: US 8,654,970 B2 Olson et al. (45) Date of Patent: Feb. 18, 2014 (54) APPARATUS AND METHOD FOR 7,321,910 B2 1/2008 Crispin IMPLEMENTING INSTRUCTION SUPPORT EE 858 silk et al. FOR THE DATA ENCRYPTION STANDARD 7.433.469 B2 10/2008 Koshy et al. (DES) ALGORITHM 7,454,016 B2 * 1 1/2008 Tsunoo ........................... 380.29 7.460.666 B2 12/2008 Morioka et al. (75) Inventors: Christopher H. Olson, Austin, TX (US); 7,496, 196 B2 * 2/2009 Jalfon et al. .................... 380.29 Gregory F. Grohoski, Bee Cave, TX 7,502.464 B2 3/2009 Macchetti et al. (US); Lawrence A. Spracklen,s Boulders 7,532,7227,502,943 B2 3/20095/2009 CrispinHenry Creek, CA (US) 7,539,876 B2 5/2009 Henry (73) Assignee: Oracle America, Inc., Redwood Shores, (Continued) CA (US) OTHER PUBLICATIONS (*) Notice: Subject to any disclaimer, the term of this Stamenkovic, Z.; Wolf, C.; Schoof, G., Gaisler, J.; "LEON-2: Gen patent is extended or adjusted under 35 eral Purpose Processor for a Wireless Engine.” Design and Diagnos U.S.C. 154(b) by 962 days. tics of Electronic Circuits and systems, 2006 IEEE, vol., no., pp. 48-51, 0-0 0;doi: 10.1109/DDECS 2006. 1649569 URL: http:// (21) Appl. No.: 12/414,755 ieeexplore.ieee.org/stampfstamp.jsp?tp=&arnumber=1649569 &isnumber=34591. (22) Filed: Mar. 31, 2009 (Continued) (65) Prior Publication Data Primary Examiner — Tae Kim US 2010/0246814 A1 Sep. 30, 2010 (74) Attorney, Agent, or Firm — Meyertons Hood Kivlin (51) Int.
    [Show full text]
  • This Document Includes Text Contributed by Nikos Mavrogiannopoulos, Simon Josefsson, Daiki Ueno, Carolin Latze, Alfredo Pironti, Ted Zlatanov and Andrew Mcdonald
    This document includes text contributed by Nikos Mavrogiannopoulos, Simon Josefsson, Daiki Ueno, Carolin Latze, Alfredo Pironti, Ted Zlatanov and Andrew McDonald. Several corrections are due to Patrick Pelletier and Andreas Metzler. ISBN 978-1-326-00266-4 Copyright © 2001-2015 Free Software Foundation, Inc. Copyright © 2001-2019 Nikos Mavrogiannopoulos Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". Contents Preface xiii 1. Introduction to GnuTLS1 1.1. Downloading and installing.............................1 1.2. Installing for a software distribution........................2 1.3. Overview.......................................3 2. Introduction to TLS and DTLS5 2.1. TLS Layers......................................5 2.2. The Transport Layer.................................5 2.3. The TLS record protocol...............................6 2.3.1. Encryption algorithms used in the record layer..............6 2.3.2. Compression algorithms and the record layer...............8 2.3.3. On record padding..............................8 2.4. The TLS alert protocol...............................9 2.5. The TLS handshake protocol............................ 10 2.5.1. TLS ciphersuites............................... 11 2.5.2. Authentication................................ 11 2.5.3. Client authentication............................. 11 2.5.4. Resuming sessions.............................. 12 2.6. TLS extensions.................................... 12 2.6.1. Maximum fragment length negotiation................... 12 2.6.2. Server name indication............................ 12 2.6.3. Session tickets................................ 13 2.6.4. HeartBeat................................... 13 2.6.5. Safe renegotiation.............................
    [Show full text]
  • U.S. Government Publishing Office Style Manual
    Style Manual An official guide to the form and style of Federal Government publishing | 2016 Keeping America Informed | OFFICIAL | DIGITAL | SECURE [email protected] Production and Distribution Notes This publication was typeset electronically using Helvetica and Minion Pro typefaces. It was printed using vegetable oil-based ink on recycled paper containing 30% post consumer waste. The GPO Style Manual will be distributed to libraries in the Federal Depository Library Program. To find a depository library near you, please go to the Federal depository library directory at http://catalog.gpo.gov/fdlpdir/public.jsp. The electronic text of this publication is available for public use free of charge at https://www.govinfo.gov/gpo-style-manual. Library of Congress Cataloging-in-Publication Data Names: United States. Government Publishing Office, author. Title: Style manual : an official guide to the form and style of federal government publications / U.S. Government Publishing Office. Other titles: Official guide to the form and style of federal government publications | Also known as: GPO style manual Description: 2016; official U.S. Government edition. | Washington, DC : U.S. Government Publishing Office, 2016. | Includes index. Identifiers: LCCN 2016055634| ISBN 9780160936029 (cloth) | ISBN 0160936020 (cloth) | ISBN 9780160936012 (paper) | ISBN 0160936012 (paper) Subjects: LCSH: Printing—United States—Style manuals. | Printing, Public—United States—Handbooks, manuals, etc. | Publishers and publishing—United States—Handbooks, manuals, etc. | Authorship—Style manuals. | Editing—Handbooks, manuals, etc. Classification: LCC Z253 .U58 2016 | DDC 808/.02—dc23 | SUDOC GP 1.23/4:ST 9/2016 LC record available at https://lccn.loc.gov/2016055634 Use of ISBN Prefix This is the official U.S.
    [Show full text]
  • Security Skills for Sysadmins
    Security Skills for Sysadmins Security Skills for Sysadmins Wieviel Kryptografie muß im root Account stecken? René ’Lynx’ Pfeiffer Crowes Agency OG ihttp://www.crowes.eu/, [email protected] Linuxwochen Wien FH Technikum Wien, Wien, Österreich. Security Skills for Sysadmins Systemadministration Table of Contents I Security Skills for Sysadmins Systemadministration Table of Contents II . 1 Systemadministration 2 Bedrohungen 3 Kryptographie 4 Zusammenfassung 5 Über die Crowes Agency OG Security Skills for Sysadmins Systemadministration Systemadministration Security Skills for Sysadmins Systemadministration Geschichte Geschichte (digitale) Hausmeierei existiert seit es Infrastruktur gibt „Sysops kümmern sich um Computer\ tatsächliches Berufsbild viel komplizierter Studienfach theoretisch Systemadministration Security Skills for Sysadmins Systemadministration Typische Tätigkeiten Typische Tätigkeiten Integration neuer Technologien in bestehende Infrastruktur Sicherstellung von Betrieb von Systemen und Software Wartungen/Upgrades/Migrationen Verwaltungsaufgaben (Konten, Resourcen, Betriebsmittel) Sicherheitsaufgaben (technische) Dokumentation Unterstützung von Anwendern/Entwicklern Datensicherung/-wiederherstellung Performance Verbesserungen ::: Security Skills for Sysadmins Systemadministration Verhältnis zur Sicherheit Verhältnis zur Sicherheit betreute Systeme sind meist exponiert Netzwerke Interaktion mit anderen Systemen Benutzereingaben Systemadministration trifft Sicherheitsprobleme zuerst Systemadministration muß Schaden verringern oder
    [Show full text]
  • VIA Isaiah Architecture Announcement FAQ
    VIA Isaiah Architecture Announcement FAQ Q1.) What is VIA Announcing? A1.) VIA is announcing its next generation VIA Isaiah Architecture. This is a completely new x86 processor architecture that has been designed from the ground up to deliver 2-to-4x higher performance while remaining within the same power envelope of the VIA C7TM processor. Future processors based on the VIA Isaiah Architecture will deliver significant boosts to the functionality and performance of desktop, mobile and ultra mobile PCs while minimizing power requirements, saving on battery life, and enabling ultra-compact system designs. Q2.) What are the key features of the new VIA Isaiah Architecture? A2.)The VIA Isaiah Architecture combines all the latest advances in x86 processor technology, including a 64-bit superscalar, speculative, out-of-order microarchitecture with high-performance multimedia computation and a new virtual machine architecture. The main highlights can be summarized as follows: a.) 64-bit Superscalar, Speculative, Out-Of-Order Microarchitecture The VIA Isaiah Architecture achieves high performance by implementing a next-generation superscalar and out-of-order architecture that is tuned to deliver the highest performance per watt while minimizing the number of transistors to keep the die size small. The architecture makes heavy use of macro-fusion and micro-fusion to increase the instruction throughput, while sophisticated branch prediction significantly improves processor efficiency and performance. The 64-bit instruction set of the VIA Isaiah architecture has no special cases that restrict flexibility, providing system designers with 64-bit instruction set with ample headroom for 64-bit operating systems and applications. The VIA Isaiah Architecture also supports a modern virtual machine architecture for running systems more securely and efficiently in virtual environments.
    [Show full text]
  • Cryptographic Hardware Accelerators
    OpenWrt Wiki Cryptographic Hardware Accelerators A Cryptographic Hardware Accelerator can be integrated into the SoC as a separate processor, as special purpose CPU (aka Core). integrated in a Coprocessor [https://en.wikipedia.org/wiki/Coprocessor] on the circuit board contained on a Chip on an extension circuit board, this can be connected to the mainboard via some BUS, e.g. PCI an ISA extension [https://en.wikipedia.org/wiki/Template:Multimedia_extensions] like e.g. AES instruction set [https://en.wikipedia.org/wiki/AES instruction set] and thus integral part of the CPU (in that case a kernel driver in not needed) The purpose is to load off the very computing intensive tasks of encryption/decryption and compression/decompression. As can be seen in this AES instruction set [https://en.wikipedia.org/wiki/AES instruction set] article, the acceleration is usually achieved by doing certain arithmetic calculation in hardware. When the acceleration is not in the instruction set of the CPU, it is supported via a kernel driver (/dev/crypto). There are two drivers offering /dev/crypto in OpenWRT: Cryptodev-linux [https://github.com/openwrt/packages/tree/master/utils/cryptodev-linux] kernel module, which utilizes the Linux kernel crypto drivers OCF (OpenBSD Crypto Framework), which utilizes the OpenBSD crypto drivers Both ways result to a /dev/crypto device which can be used by userspace crypto applications (e.g., the ones that utilize openssl or gnutls). Performance Depending on which arithmetic calculations exactly are being done in the specific hardware, the results differ widely. You should not concern yourself with theoretical bla,bla but find out how a certain implementation performs in the task you want to do with it! You could want to you could attach a USB drive to your device and mount a local filesystem like ext3 from it.
    [Show full text]
  • Linux Cryptographic Acceleration on an I.MX6
    Linux Cryptographic Acceleration on an i.MX6 Sean Hudson Embedded Linux Architect mentor.com/embedded Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners. Who am I? I am an embedded Linux architect and Member of Technical Staff at Mentor Graphics. I have worked on embedded devices since 1996. I started working with Linux as a hobbyist in 1999 and professionally with embedded Linux in 2006. In OSS, I have been involved with the Yocto Project since it's public announcement in 2010, have served on the YP Advisory Board for two different companies, and am currently a member of the OpenEmbedded Board. 2 www.mentor.com/embedded A special word of thanks Much of the hard work gathering data for this presentation was done by a co-worker, Wade Farnsworth, who was unable to attend today. 3 www.mentor.com/embedded Outline About this presentation A word about Cryptography Crypto Hardware types i.MX6 CAAM Kernel access to HW Application access to HW Test methods Results Conclusions and final thoughts Q&A / Discussion 4 www.mentor.com/embedded About this presentation This talk is geared towards using cryptographic hardware acceleration from user space — I won’t spend a lot of time on kernel internals and drivers The focus comes from work that we did with the
    [Show full text]