DOCSLIB.ORG

ASLR: How Robust Is the Randomness? Quantifying Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ASLR: How Robust Is the Randomness? Quantifying Security Quantifying Security to Advance Resilience ASLR: How Robust is the Randomness? Jonathan Ganz What is Address Space Layout Randomization? ● Provides System-Level Control-Flow Integrity ● Adds Random Memory Offsets to Binaries ● Makes Buffer Overflows Harder to Exploit ⚫ Does Not Completely Remove Vulnerability ● Strength of ASLR Depends on Entropy of Offsets 2 What are Buffer Overflows? 3 https://www.securitysift.com/windows-exploit-development-part-2-intro-stack-overflow/ Why Attackers Perform Buffer Overflows AAAAAAAAAA AAAAAAAAAA AAAAAAAAAA AAAAAAAAAA AAAAAAA AAAAAAAAAA AAAAA AAAAAAA AAAAAAAAAA AAAAA AAAAAAA AAAAAAAAAA AAAAA AAAQRST 4 Why We Use ASLR ● Organizations Often Rely on Third-Party Software ● This Software May Be Vulnerable & Closed-Source ● Extra Hardening Features May Not Be Available ⚫ CPU Power ⚫ Thermal Design Power ⚫ Licensing / Cost ⚫ Architecture Compatibility 5 Motivation ● We Rely on Certain Security Features ● How Reliable are these Features? ● How Much Defense Does ASLR Provide? ● Remote Security Evaluation 6 ASLR Experiment ● Measure Entropy of ASLR Implementations ● Develop Buffer-Overflow-Vulnerable Program ● Develop Attack Program (Inspired by Blind-ROP) ● Evaluate Multiple Operating Systems ⚫ Debian, OpenBSD, HardenedBSD ⚫ 32-bit and 64-bit Architectures ● Perform Hundreds of Measurements 7 ASLR Assumption ● 64-bit Operating Systems Represent Memory with More Bits than their 32-bit Variants ● The 64-bit Versions Have More Bits Available to Manipulate Through ASLR ● 64-bit Implementations of ASLR Should Provide More Entropy than 32-bit Implementations 8 Claims of Entropy Provided by ASLR Entropy Claimed 64-bit HardenedBSD 30 bits 64-bit Debian 28 bits 64-bit OpenBSD 25 bits 32-bit Debian 24 bits 32-bit OpenBSD 16 bits 32-bit HardenedBSD 14 bits 9 Vulnerable Network Service fork() Request Server Client Child 10 Attacking the Vulnerable Service AtkStr Running? Crashed? Target Function? 11 Attack Strategy [0] 12 Attack Strategy [0] 13 Attack Strategy [0] ✔ Running 14 Attack Strategy [0] ✔ [0][0] 15 Attack Strategy [0] ✔ [0][0] 16 Attack Strategy [0] ✔ [0][0] ✔ Running 17 Attack Strategy [0] ✔ [0][0] ✔ [0][0][0] ✔ 18 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . 19 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ 20 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ 21 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ 22 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ 23 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ 24 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ 25 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] ✔ 26 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] ✔ [0][0][0]....[0][137][0] ✘ 27 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] ✔ [0][0][0]....[0][137][0] ✘ [0][0][0]....[0][137][1] ✘ 28 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] ✔ [0][0][0]....[0][137][0] ✘ [0][0][0]....[0][137][1] ✘ . ✘ . ✘ 29 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] ✔ [0][0][0]....[0][137][0] ✘ [0][0][0]....[0][137][1] ✘ . ✘ . ✘ [0][0][0]....[0][137][14][213][57] ✔ 30 Attack Strategy ✔ [0] ✔ [0][0] ✔ [0][0][0] . ✔ . ✔ [0][0][0]....[0] ✔ [0][0][0]....[0][0] ✘ [0][0][0]....[0][1] ✘ [0][0][0]....[0][2] ✘ . ✘ . ✘ [0][0][0]....[0][137] [137][14][213][57] ✔ [0][0][0]....[0][137][0] ✘ [0][0][0]....[0][137][1] ✘ . ✘ . ✘ [0][0][0]....[0][137][14][213][57] ✔ 31 ASLR Results - 32-bit HardenedBSD 32 ASLR Results - 32-bit OpenBSD 33 ASLR Results - 64-bit OpenBSD 34 ASLR Results - 32-bit Debian Linux 35 ASLR Results - 64-bit HardenedBSD 36 ASLR Results - 64-bit Debian Linux 37 ASLR Results - 32-bit HardenedBSD 38 ASLR Results - 32-bit OpenBSD 39 ASLR Results - 64-bit OpenBSD 40 ASLR Results - 32-bit Debian Linux 41 ASLR Results - 64-bit HardenedBSD 42 ASLR Results - 64-bit Debian Linux 43 ASLR Results - Effective Entropy Claimed Measured 64-bit Debian 28 bits 28 bits 64-bit HardenedBSD 30 bits 25 bits 32-bit Debian 24 bits 20 bits 64-bit OpenBSD 25 bits 15 bits 32-bit OpenBSD 16 bits 15 bits 32-bit HardenedBSD 14 bits 8 bits 44 Evaluation ● Debian (32-bit & 64-bit) ASLR Has Most Entropy ● 32-bit HardenedBSD ASLR Has Least Entropy ● Operating Systems Often Provide Less Entropy than Claimed ● We Must Perform Independent Tests of Security ● Evaluation Can Be Performed on More OSes 45 Limitations ● Small Set of Operating Systems Tested ❌ Windows ❌ macOS ❌ Android ❌ iOS ● Source Code Was Not Examined 46 Related Work ● “A Study of MAC Address Randomization in Mobile Devices and When it Fails” - Martin et al. ● “Techniques for the Dynamic Randomization of Network Attributes” - Chavez et al. 47 Conclusion ● Strength of Security Features Should Be Verified ● More Analysis Reveals Existing Limitations ● This Work Looks at Only One Defense Mechanism ● We Need More Quantitative Security Metrics 48 Questions? www.jonganz.com Security Research ● Malicious Media Sanitization ● Performance Analysis of Network Monitors ● Electronic Voting System Security Evaluation ● Multipath Routing Recovery Delay www.jonganz.com.
Load more

Recommended publications
  • Oracle Solaris 11.4 Security Target, V1.3
    Oracle Solaris 11.4 Security Target Version 1.3 February 2021 Document prepared by www.lightshipsec.com Oracle Security Target Document History Version Date Author Description 1.0 09 Nov 2020 G Nickel Update TOE version 1.1 19 Nov 2020 G Nickel Update IDR version 1.2 25 Jan 2021 L Turner Update TLS and SSH. 1.3 8 Feb 2021 L Turner Finalize for certification. Page 2 of 40 Oracle Security Target Table of Contents 1 Introduction ........................................................................................................................... 5 1.1 Overview ........................................................................................................................ 5 1.2 Identification ................................................................................................................... 5 1.3 Conformance Claims ...................................................................................................... 5 1.4 Terminology ................................................................................................................... 6 2 TOE Description .................................................................................................................... 9 2.1 Type ............................................................................................................................... 9 2.2 Usage ............................................................................................................................. 9 2.3 Logical Scope ................................................................................................................
    [Show full text]
  • Cryptanalysis of the Random Number Generator of the Windows Operating System
    Cryptanalysis of the Random Number Generator of the Windows Operating System Leo Dorrendorf School of Engineering and Computer Science The Hebrew University of Jerusalem 91904 Jerusalem, Israel [email protected] Zvi Gutterman Benny Pinkas¤ School of Engineering and Computer Science Department of Computer Science The Hebrew University of Jerusalem University of Haifa 91904 Jerusalem, Israel 31905 Haifa, Israel [email protected] [email protected] November 4, 2007 Abstract The pseudo-random number generator (PRNG) used by the Windows operating system is the most commonly used PRNG. The pseudo-randomness of the output of this generator is crucial for the security of almost any application running in Windows. Nevertheless, its exact algorithm was never published. We examined the binary code of a distribution of Windows 2000, which is still the second most popular operating system after Windows XP. (This investigation was done without any help from Microsoft.) We reconstructed, for the ¯rst time, the algorithm used by the pseudo- random number generator (namely, the function CryptGenRandom). We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(223) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. We also analyzed the way in which the generator is run by the operating system, and found that it ampli¯es the e®ect of the attacks: The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges.
    [Show full text]
  • Vulnerabilities of the Linux Random Number Generator
    Black Hat 2006 Open to Attack Vulnerabilities of the Linux Random Number Generator Zvi Gutterman Chief Technology Officer with Benny Pinkas Tzachy Reinman Zvi Gutterman CTO, Safend Previously a chief architect in the IP infrastructure group for ECTEL (NASDAQ:ECTX) and an officer in the Israeli Defense Forces (IDF) Elite Intelligence unit. Master's and Bachelor's degrees in Computer Science from the Israeli Institute of Technology. Ph.D. candidate at the Hebrew University of Jerusalem, focusing on security, network protocols, and software engineering. - Proprietary & Confidential - Safend Safend is a leading provider of innovative endpoint security solutions that protect against corporate data leakage and penetration via physical and wireless ports. Safend Auditor and Safend Protector deliver complete visibility and granular control over all enterprise endpoints. Safend's robust, ultra- secure solutions are intuitive to manage, almost impossible to circumvent, and guarantee connectivity and productivity, without sacrificing security. For more information, visit www.safend.com. - Proprietary & Confidential - Pseudo-Random-Number-Generator (PRNG) Elementary and critical component in many cryptographic protocols Usually: “… Alice picks key K at random …” In practice looks like random.nextBytes(bytes); session_id = digest.digest(bytes); • Which is equal to session_id = md5(get next 16 random bytes) - Proprietary & Confidential - If the PRNG is predictable the cryptosystem is not secure Demonstrated in - Netscape SSL [GoldbergWagner 96] http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Apache session-id’s [GuttermanMalkhi 05] http://www.gutterman.net/publications/2005/02/hold_your_sessions_an_attack_o.html - Proprietary & Confidential - General PRNG Scheme 0 0 01 Stateseed 110 100010 Properties: 1. Pseudo-randomness Output bits are indistinguishable from uniform random stream 2.
    [Show full text]
  • Analysis of Entropy Usage in Random Number Generators
    DEGREE PROJECT IN THE FIELD OF TECHNOLOGY ENGINEERING PHYSICS AND THE MAIN FIELD OF STUDY COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2017 Analysis of Entropy Usage in Random Number Generators KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF COMPUTER SCIENCE AND COMMUNICATION Analysis of Entropy Usage in Random Number Generators JOEL GÄRTNER Master in Computer Science Date: September 16, 2017 Supervisor: Douglas Wikström Examiner: Johan Håstad Principal: Omegapoint Swedish title: Analys av entropianvändning i slumptalsgeneratorer School of Computer Science and Communication i Abstract Cryptographically secure random number generators usually require an outside seed to be initialized. Other solutions instead use a continuous entropy stream to ensure that the internal state of the generator always remains unpredictable. This thesis analyses four such generators with entropy inputs. Furthermore, different ways to estimate entropy is presented and a new method useful for the generator analy- sis is developed. The developed entropy estimator performs well in tests and is used to analyse en- tropy gathered from the different generators. Furthermore, all the analysed generators exhibit some seemingly unintentional behaviour, but most should still be safe for use. ii Sammanfattning Kryptografiskt säkra slumptalsgeneratorer behöver ofta initialiseras med ett oförutsägbart frö. En annan lösning är att istället konstant ge slumptalsgeneratorer entropi. Detta gör det möjligt att garantera att det interna tillståndet i generatorn hålls oförutsägbart. I den här rapporten analyseras fyra sådana generatorer som matas med entropi. Dess- utom presenteras olika sätt att skatta entropi och en ny skattningsmetod utvecklas för att användas till analysen av generatorerna. Den framtagna metoden för entropiskattning lyckas bra i tester och används för att analysera entropin i de olika generatorerna.
    [Show full text]
  • Trusted Platform Module ST33TPHF20SPI FIPS 140-2 Security Policy Level 2
    STMICROELECTRONICS Trusted Platform Module ST33TPHF20SPI ST33HTPH2E28AAF0 / ST33HTPH2E32AAF0 / ST33HTPH2E28AAF1 / ST33HTPH2E32AAF1 ST33HTPH2028AAF3 / ST33HTPH2032AAF3 FIPS 140-2 Security Policy Level 2 Firmware revision: 49.00 / 4A.00 HW version: ST33HTPH revision A Date: 2017/07/19 Document Version: 01-11 NON-PROPRIETARY DOCUMENT FIPS 140-2 SECURITY POLICY NON-PROPRIETARY DOCUMENT Page 1 of 43 Table of Contents 1 MODULE DESCRIPTION .................................................................................................................... 3 1.1 DEFINITION ..................................................................................................................................... 3 1.2 MODULE IDENTIFICATION ................................................................................................................. 3 1.2.1 AAF0 / AAF1 ......................................................................................................................... 3 1.2.2 AAF3 ..................................................................................................................................... 4 1.3 PINOUT DESCRIPTION ...................................................................................................................... 6 1.4 BLOCK DIAGRAMS ........................................................................................................................... 8 1.4.1 HW block diagram ...............................................................................................................
    [Show full text]
  • Dev/Random and FIPS
    /dev/random and Your FIPS 140-2 Validation Can Be Friends Yes, Really Valerie Fenwick Manager, Solaris Cryptographic Technologies team Oracle May 19, 2016 Photo by CGP Grey, http://www.cgpgrey.com/ Creative Commons Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Not All /dev/random Implementations Are Alike • Your mileage may vary – Even across OS versions – Solaris 7‘s /dev/random is nothing like Solaris 11’s – Which look nothing like /dev/random in Linux, OpenBSD, MacOS, etc – Windows gets you a whole ‘nother ball of wax… • No common ancestry – Other than concept Copyright © 2016, Oracle and/or its affiliates. All rights reserved 3 /dev/random vs /dev/urandom • On most OSes, /dev/urandom is a PRNG (Pseudo-Random Number Generator) – In some, so is their /dev/random • Traditionally, /dev/urandom will never block – /dev/random will block • For fun, on some OSes /dev/urandom is a link to /dev/random Copyright © 2016, Oracle and/or its affiliates. All rights reserved 4 FreeBSD: /dev/random • /dev/urandom is a link to /dev/random • Only blocks until seeded • Based on Fortuna Copyright © 2016, Oracle and/or its affiliates. All rights reserved 5 OpenBSD: /dev/random • Called /dev/arandom • Does not block • Formerly based on ARCFOUR – Now based on ChaCha20 – C API still named arc4random() Copyright © 2016, Oracle and/or its affiliates. All rights reserved 6 MacOS: /dev/random • /dev/urandom is a link to /dev/random • 160-bit Yarrow PRNG, uses SHA1 and 3DES Copyright © 2016, Oracle and/or its affiliates. All rights reserved 7 Linux: /dev/random • Blocks when entropy is depleted • Has a separate non-blocking /dev/urandom Copyright © 2016, Oracle and/or its affiliates.
    [Show full text]
  • Linux Random Number Generator
    Not-So-Random Numbers in Virtualized Linux and the Whirlwind RNG Adam Everspaugh, Yan Zhai, Robert Jellinek, Thomas Ristenpart, Michael Swift Department of Computer Sciences University of Wisconsin-Madison {ace, yanzhai, jellinek, rist, swift}@cs.wisc.edu Abstract—Virtualized environments are widely thought to user-level cryptographic processes such as Apache TLS can cause problems for software-based random number generators suffer a catastrophic loss of security when run in a VM that (RNGs), due to use of virtual machine (VM) snapshots as is resumed multiple times from the same snapshot. Left as an well as fewer and believed-to-be lower quality entropy sources. Despite this, we are unaware of any published analysis of the open question in that work is whether reset vulnerabilities security of critical RNGs when running in VMs. We fill this also affect system RNGs. Finally, common folklore states gap, using measurements of Linux’s RNG systems (without the that software entropy sources are inherently worse on virtu- aid of hardware RNGs, the most common use case today) on alized platforms due to frequent lack of keyboard and mouse, Xen, VMware, and Amazon EC2. Despite CPU cycle counters interrupt coalescing by VM managers, and more. Despite providing a significant source of entropy, various deficiencies in the design of the Linux RNG makes its first output vulnerable all this, to date there have been no published measurement during VM boots and, more critically, makes it suffer from studies evaluating the security of Linux (or another common catastrophic reset vulnerabilities. We show cases in which the system RNG) in modern virtualized environments.
    [Show full text]
  • Analysis of the Linux Random Number Generator
    Analysis of the Linux Random Number Generator Zvi Gutterman Benny Pinkas Safend and The Hebrew University of Jerusalem University of Haifa Tzachy Reinman The Hebrew University of Jerusalem March 6, 2006 Abstract Linux is the most popular open source project. The Linux random number generator is part of the kernel of all Linux distributions and is based on generating randomness from entropy of operating system events. The output of this generator is used for almost every security protocol, including TLS/SSL key generation, choosing TCP sequence numbers, and file system and email encryption. Although the generator is part of an open source project, its source code (about 2500 lines of code) is poorly documented, and patched with hundreds of code patches. We used dynamic and static reverse engineering to learn the operation of this generator. This paper presents a description of the underlying algorithms and exposes several security vulnerabilities. In particular, we show an attack on the forward security of the generator which enables an adversary who exposes the state of the generator to compute previous states and outputs. In addition we present a few cryptographic flaws in the design of the generator, as well as measurements of the actual entropy collected by it, and a critical analysis of the use of the generator in Linux distributions on disk-less devices. 1 Introduction Randomness is a crucial resource for cryptography, and random number generators are therefore critical building blocks of almost all cryptographic systems. The security analysis of almost any system assumes a source of random bits, whose output can be used, for example, for the purpose of choosing keys or choosing random nonces.
    [Show full text]
  • Random Number Generation (Entropy)
    1 ì Random Number Generation (Entropy) Secure Software Systems Fall 2018 2 Entropy (Thermodynamics) Measure of disorder of any system Entropy will only increase over time! (2nd law of thermodynamics) Secure Software Systems Fall 2018 3 Entropy (Information Science) ì Shannon Entropy ì Measure of unpredictability of a state ì Average information content ì Low entropy ì Very predictable ì Not much information contained ì High entropy ì Unpredictable Desired for cryptography! ì Significant information contained Secure Software Systems Fall 2018 4 Donald Knuth ì Author, The Art of Computer Programming ì Algorithms! ì Creator of TeX typesetting system ì Winner, ACM Turing Award, 1974 “Random numbers should not be generated with a method chosen at random.” – Donald Knuth Secure Software Systems Fall 2018 5 The Market ì High demand for random numbers in cryptography ì Keys ì Nonces ì One-time pads ì Salts Secure Software Systems Fall 2018 6 Great Disasters in Random Numbers ì Netscape Navigator (1995) ì Random numbers used for SSL encryption ì Export laws (at time) limited international version to 40 bit key lengths ì Algorithm RNG_CreateContext() ì Generates seed for RNG ì Get time of day, process ID, parent process ID ì Hash with MD5 ì All predictable! ì Brute force in much fewer than 240 attempts, which was already weak (< 30 hours) https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html Secure Software Systems Fall 2018 7 Great Disasters in Random Numbers ì Debian Linux (2006-2008) - CVE-2008-0166 ì OpenSSL package (specific Debian/Ubuntu
    [Show full text]
  • Documentation and Analysis of the Linux Random Number Generator
    Documentation and Analysis of the Linux Random Number Generator Version: 3.6 Document history Version Date Editor Description 2.0 2018-03-21 Stephan Müller Covering kernel 4.15 Re-running all tests of chapters 6 and following on 4.15 2.1 2018-04-11 Stephan Müller Updating the test results for the reboot tests on bare metal with 50,000 reboot cycles 2.2 2018-04-11 Stephan Müller Covering kernel 4.16 2.3 2018-06-18 Stephan Müller Covering kernel 4.17 2.4 2018-08-24 Stephan Müller Covering kernel 4.18 2.5 2018-11-12 Stephan Müller Covering kernel 4.19 Updated seeding process ChaCha20 DRNG documented 2.6 2019-01-11 Stephan Müller Covering kernel 4.20 3.0 2019-04-05 Stephan Müller Covering kernel 5.0 Re-running all tests of chapters 6 and following on 5.0 3.1 2019-04-12 Stephan Müller Adding results of reboot-tests for 5.0 3.2 2019-05-17 Stephan Müller Addressing comments from BSI Covering kernel 5.1 3.3 2019-08-13 Stephan Müller Covering kernel 5.2 3.4 2019-09-26 Stephan Müller Covering kernel 5.3 3.5 2019-12-13 Stephan Müller Covering kernel 5.4 3.6 2020-04-07 Stephan Müller Covering kernel 5.5 Federal Office for Information Security Post Box 20 03 63 D-53133 Bonn Internet: https://www.bsi.bund.de © Federal Office for Information Security 2020 Document history This analysis was prepared for BSI by atsec information security GmbH.
    [Show full text]
  • Cryptography in Openbsd
    Cryptography in Op enBSD: An Overview Theo de Raadt, Niklas Hallqvist, Artur Grab owski, Angelos D. Keromytis, Niels Provos fderaadt,niklas,art,angelos,provosg@op enbsd.org The OpenBSD Project Abstract trying to make their use as easy and, where p ossi- ble, transparent to the end user. Thus, more work Cryptographic mechanisms are an imp ortant se- is done in those mechanisms that can be used to curity comp onent of an op erating system in secur- provide transparent security, e.g., IPsec. ing the system itself and its communication paths. With this pap er, weintend to give a good overview Indeed, in many situations, cryptography is the of the cryptography currently distributed and used only to ol that can solve a particular problem, e.g., in Op enBSD, and of our plans for future work. We network-level security. While cryptography by it- hop e this will b e of interest b oth to end-users and ad- self do es not guarantee security, when applied cor- ministrators lo oking for b etter ways to protect their rectly, it can signi cantly improve overall security. host and networks, and to develop ers in other sys- Since one of the main fo ci of the Op enBSD system is tems free or otherwise that are considering sup- security,various cryptographic mechanisms are em- p orting some of these mechanisms. We should again ployed in a numb er of di erent roles. caution the readers, however, that cryptography This pap er gives an overview of the cryptography do es not solve all security problems in an op erat- employed in Op enBSD.
    [Show full text]
  • Processor Package Security Infrastructure SAFE G0 Review
    Solving The Platform Entropy Problem George Cox Security Architect Intel Corporation Session Introduction Much of computer security is based upon the use of cryptography. Cryptography is based upon two things: • Good algorithms (e.g., AES) and • Good keys (e.g., good random numbers). Historically, computing platforms broadly have not had high quality/high performance entropy (or random numbers). By enabling ALL future Intel platforms with our RdRand instruction (supported by our underlying Digital Random Number Generator (DRNG)), we: Provide a fundamental solution to the long standing “Platform Entropy Problem” and Give Intel’s customers the “common brand promise” of high quality/high performance entropy (or random numbers) everywhere across ALL Intel products in which it is embedded. => the “Platform Entropy Problem” just “goes away” on future Intel-based platforms. Agenda The Platform’s Need For Entropy The Platform Entropy Problem Examples of RNG-based Security Attacks Serendipity Happens Our Solution SW Interface – The RdRand Instruction The DRNG RdRand/DRNG Deployment Processor Embedding Example Performance Measured Throughput Response Time and Reseeding Frequency Summary The Platform’s Need For Entropy Entropy is valuable in a variety of uses, the first of which that comes to mind being for “keying material” in cryptography. Cryptography is a basic building block for modern computer security and is based upon the use of comparably high quality algorithms and keys. Either being “weak” has resulted in successful attacks on cryptographic systems. Over time, cryptographic algorithms and their implementations have continually been improved, as needed (e.g., our AES NI). Comparably, the availability, quality, and performance of entropy sources have not.
    [Show full text]