DOCSLIB.ORG

On the Practical Exploitability of Dual EC in TLS Implementations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On the Practical Exploitability of Dual EC in TLS Implementations On the Practical Exploitability of Dual EC in TLS Implementations Stephen Checkoway, Johns Hopkins University; Matthew Fredrikson, University of Wisconsin—Madison; Ruben Niederhagen, Technische Universiteit Eindhoven; Adam Everspaugh, University of Wisconsin—Madison; Matthew Green, Johns Hopkins University; Tanja Lange, Technische Universiteit Eindhoven; Thomas Ristenpart, University of Wisconsin—Madison; Daniel J. Bernstein, Technische Universiteit Eindhoven and University of Illinois at Chicago; Jake Maskiewicz and Hovav Shacham, University of California, San Diego https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/checkoway This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX On the Practical Exploitability of Dual EC in TLS Implementations Stephen Checkoway,1 Matthew Fredrikson,2 Ruben Niederhagen,3 Adam Everspaugh,2 Matthew Green,1 Tanja Lange,3 Thomas Ristenpart,2 Daniel J. Bernstein,3,4 Jake Maskiewicz,5 and Hovav Shacham5 1 Johns Hopkins University, 2 University of Wisconsin, 3 Technische Universiteit Eindhoven, 4 University of Illinois at Chicago, 5 UC San Diego Abstract The documents also make specific reference to a This paper analyzes the actual cost of attacking TLS im- set of pseudorandom number generator (PRNG) algo- plementations that use NIST’s Dual EC pseudorandom rithms adopted as part of the National Institute of Stan- number generator, assuming that the attacker generated dards and Technology (NIST) Special Publication 800- the constants used in Dual EC. It has been known for 90 [21] in 2006, and also standardized as part of ISO several years that an attacker generating these constants 18031 [15]. These standards include an algorithm called and seeing a long enough stretch of Dual EC output bits the Dual Elliptic Curve Deterministic Random Bit Gen- can predict all future outputs; but TLS does not natu- erator (Dual EC). As a result of these revelations, NIST rally provide a long enough stretch of output bits, and the reopened the public comment period for SP 800-90. cost of an attack turns out to depend heavily on choices Known weaknesses in Dual EC. Long before 2013, made in implementing the RNG and on choices made in Dual EC had been identified by the security community implementing other parts of TLS. as biased [8, 27], extremely slow, and backdoorable. Specifically, this paper investigates OpenSSL-FIPS, SP 800-90 had already noted that “elliptic curve arith- Windows’ SChannel, and the C/C++ and Java versions of metic” makes Dual EC generate “pseudorandom bits more the RSA BSAFE library. This paper shows that Dual EC slowly than the other DRBG mechanisms in this Recom- exploitability is fragile, and in particular is stopped by an mendation” [21, p. 177] but had claimed that the Dual EC outright bug in the certified Dual EC implementation in design “allows for certain performance-enhancing possi- OpenSSL. On the other hand, this paper also shows that bilities.” In fact, Dual EC with all known optimizations Dual EC exploitability benefits from a modification made is two orders of magnitude slower than the other PRNGs, to the Dual EC standard in 2007; from several attack op- because it uses scalar multiplications on an elliptic curve timizations introduced here; and from various proposed where the other PRNGs use a hash function or cipher TLS extensions, one of which is implemented in BSAFE, call. though disabled in the version we obtained and stud- The back door is a less obvious issue, first brought to ied. The paper’s attacks are implemented; benchmarked; public attention by Shumow and Ferguson [28] in 2007. tested against libraries modified to use new Dual EC con- What Shumow and Ferguson showed was that an attacker stants; and verified to successfully recover TLS plaintext. specifying Dual EC, and inspecting some Dual EC output bits from an unknown seed, had the power to predict all 1 Introduction subsequent output bits. Specifically, the description of Dual EC standardizes On September 5, 2013, the New York Times [23], the three parameter sets, each specifying an elliptic curve E Guardian [3] and ProPublica [16] reported the existence over a finite field , together with points P and Q on E. of a secret National Security Agency SIGINT Enabling Fp The back door is knowledge of d = log P, the discrete Project with the mission to “actively [engage] the US and Q logarithm of P to the base Q; an attacker creating P and foreign IT industries to covertly influence and/or overtly Q can be assumed to know d. Shumow and Ferguson leverage their commercial products’ designs.” The re- showed that knowledge of d, together with about log p vealed source documents describe a US $250 million/year 2 consecutive output bits,1 makes it feasible to predict all program designed to “make [systems] exploitable through subsequent Dual EC output. SIGINT collection” by inserting vulnerabilities, collect- ing target network data, and influencing policies, stan- Shumow and Ferguson suggested as countermeasures dards and specifications for commercial public key tech- to vary P and Q and to reduce the number of output bits nologies. Named targets include protocols for “TLS/SSL, per iteration of the PRNG. However, SP 800-90 requires https (e.g. webmail), SSH, encrypted chat, VPNs and a particular number of bits per iteration, and states that encrypted VOIP.” the standard P and Q “shall be used in applications re- *Date of this document: 2014.06.06. 1256 bits were sufficient in all their P-256 experiments. 1 USENIX Association 23rd USENIX Security Symposium 319 Table 1: Summary of our results for Dual EC using NIST P-256. Default Cache Ext. Bytes per Adin Attack Time Library PRNG Output Random Session Entropy Complexity (minutes) † 15 BSAFE-C v1.1 31–60 — 30 2 (Cv +Cf ) 0.04 † · 31 BSAFE-Java v1.1 28 — 2 (Cv + 5Cf ) 63.96 ‡ 31 SChannel I 28 — 2 (Cv + 4Cf ) 62.97 ‡ 33 17 SChannel II 30 — 2 (Cv +Cf )+2 (5Cf ) 182.64 * 15 20 OpenSSL-fixed I 32 20 2 (Cv + 3Cf )+2 (2Cf ) 0.02 OpenSSL-fixed III** 32 35 + k 215(C + 3C )+235+k(2C ) 2k 83.32 v f f · * Assuming process ID and counter known. ** Assuming 15 bits of entropy in process ID, maximum counter of 2k. See Section 4.3. † With a library–compile-time flag. ‡ Versions tested: Windows 7 64-bit Service Pack 1 and Windows Server 2010 R2. The entries in the table are for normal TLS connections. In particular, we exclude all forms of session resumption. A in the Default PRNG column indicates whether Dual EC is the default PRNG used by the library. A in the Cache Output column indicates that the unused Dual EC output is cached for use in a subsequent call. A in the Ext. Random column indicates that the proposed TLS extension Extended Random [25] is supported in some configuration. Reported attack times do not rely on use of Extended Random. Bytes per Session indicates how many contiguous, useful output bytes from Dual EC a TLS server’s handshake message reveals. For SChannel II this is an average value of useful bits, see Section 4.2. Adin Entropy indicates how many bits of unknown input are added to each Dual EC generate call. The Attack Complexity is the computational cost in terms of the cost of a scalar multiplication with a variable base point, Cv, and a fixed base point, Cf , in the worst case. With our optimizations (see Section 5), Cf is roughly 20 times faster than Cv; the exact speedup depends on context. The Time column gives our measured worst-case time for the attack on a four-node, quad-socket AMD Opteron 6276 cluster; the time for OpenSSL-fixed III is measured using k = 0. quiring certification under FIPS 140-2”; this stops use of dependently, quietly, by Brown and Vanstone in a patent alternative points in certified implementations. application [4]) turns out to be highly oversimplified: it Risk assessment for this back door depends on the prob- does not consider critical limitations and variations in ability that the creator of P and Q is an attacker. Shumow the amount of PRNG output actually exposed in TLS, and Ferguson wrote “WHAT WE ARE NOT SAYING: additional inputs to the PRNG, PRNG reseeding, align- NIST intentionally put a back door in this PRNG”; but ment of PRNG outputs, and outright bugs in Dual EC the September 2013 news indicates that NSA may have implementations. deliberately engineered Dual EC with a back door. Our We present not just a theoretical evaluation of TLS concern in this paper is not with this probability assess- vulnerability but an in-depth analysis of Dual EC in four ment, but rather with impact assessment, especially for recent implementations of TLS: RSA BSAFE Share for the use of Dual EC in TLS. C/C++ (henceforth BSAFE-C), RSA BSAFE Share for Use of Dual EC in products. Despite the known weak- Java (henceforth BSAFE-Java), Windows SChannel, and nesses in Dual EC, several vendors have implemented OpenSSL. The Network Security Services (NSS) libraries, Dual EC in their products [22]. For example, OpenSSL- e.g., used by Mozilla Firefox, and the TLS implementa- FIPS v2 and Microsoft’s SChannel include Dual EC, and tion of BlackBerry do not offer a Dual EC implementation RSA’s crypto libraries use Dual EC by default. RSA Ex- and thus are not discussed here. ecutive Chairman Art Coviello, responding to news that To experimentally verify the actual performance of our NSA had paid RSA to use Dual EC [18], stated during attacks, we replace the NIST-specified constants with ones the opening speech of RSA Conference 2014: “Given we generate; for BSAFE and Windows this required exten- that RSA’s market for encryption tools was increasingly sive reverse-engineering of binaries to find not just P and limited to the US Federal government and organizations Q but many implementation-specific constants and run- selling applications to the federal government, use of this time test vectors derived from P and Q (see Section 4.4).
Load more

Recommended publications
  • Effective Cryptography What’S Wrong with All These Crypto Apis?
    Effective Cryptography What’s Wrong With All These Crypto APIs? Thorsten Groetker, CTO Utimaco, Inc. Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 1 Outline § What I mean by Effective Cryptography § Crypto APIs § Security § Ease of Use § Runtime Performance § Predictions § CryptoScript in a Nutshell § Outlook Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 2 Effective Cryptography Definition in a Nutshell Cryptography is effective if it is Li lingues es membres del sam familie. Lor separat existentie es 1. Secure unJCE/JCA myth. Por scientie, musica , sport etc, litot li sam vocabular. Li lingues differe solmen in li grammaticaOpenSSL, li pronunciation e li pluEVP commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi 2. Efficient far uniform grammaticaPKCS#11, pronunciation e plu sommun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu CAPIsimplic e regulari quam ti del coalescent lingues. Li nov lingua CNG a. Time to Result franca va esser plu simplic e regulari quam li existent Bouncy linguesCastle. I b. Performance What’s wrong with all these crypto APIs? (Focused on Hardware Security Modules) Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 3 Problem #1: Security PKCS#11 § Numerous key extraction attacks known § Jolyon Clulow “On the Security of PKCS#11” § Tookan project (e.g., “Attacking and Fixing PKCS#11 Security Tokens”) § CVE entries (not necessarily sporting “PKCS#11” in the text)
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Anonymity in a Time of Surveillance
    LESSONS LEARNED TOO WELL: ANONYMITY IN A TIME OF SURVEILLANCE A. Michael Froomkin* It is no longer reasonable to assume that electronic communications can be kept private from governments or private-sector actors. In theory, encryption can protect the content of such communications, and anonymity can protect the communicator’s identity. But online anonymity—one of the two most important tools that protect online communicative freedom—is under practical and legal attack all over the world. Choke-point regulation, online identification requirements, and data-retention regulations combine to make anonymity very difficult as a practical matter and, in many countries, illegal. Moreover, key internet intermediaries further stifle anonymity by requiring users to disclose their real names. This Article traces the global development of technologies and regulations hostile to online anonymity, beginning with the early days of the Internet. Offering normative and pragmatic arguments for why communicative anonymity is important, this Article argues that anonymity is the bedrock of online freedom, and it must be preserved. U.S. anti-anonymity policies not only enable repressive policies abroad but also place at risk the safety of anonymous communications that Americans may someday need. This Article, in addition to providing suggestions on how to save electronic anonymity, calls for proponents of anti- anonymity policies to provide stronger justifications for such policies and to consider alternatives less likely to destroy individual liberties. In
    [Show full text]
  • Making Sense of Snowden, Part II: What's Significant in the NSA
    web extra Making Sense of Snowden, Part II: What’s Significant in the NSA Revelations Susan Landau, Google hen The Guardian began publishing a widely used cryptographic standard has vastly wider impact, leaked documents from the National especially because industry relies so heavily on secure Inter- Security Agency (NSA) on 6 June 2013, net commerce. Then The Guardian and Der Spiegel revealed each day brought startling news. From extensive, directed US eavesdropping on European leaders7 as the NSA’s collection of metadata re- well as broad surveillance by its fellow members of the “Five cords of all calls made within the US1 Eyes”: Australia, Canada, New Zealand, and the UK. Finally, to programs that collected and stored data of “non-US” per- there were documents showing the NSA targeting Google and W2 8,9 sons to the UK Government Communications Headquarters’ Yahoo’s inter-datacenter communications. (GCHQs’) interception of 200 transatlantic fiberoptic cables I summarized the initial revelations in the July/August is- at the point where they reached Britain3 to the NSA’s pene- sue of IEEE Security & Privacy.10 This installment, written in tration of communications by leaders at the G20 summit, the late December, examines the more recent ones; as a Web ex- pot was boiling over. But by late June, things had slowed to a tra, it offers more details on the teaser I wrote for the January/ simmer. The summer carried news that the NSA was partially February 2014 issue of IEEE Security & Privacy magazine funding the GCHQ’s surveillance efforts,4 and The Guardian (www.computer.org/security).
    [Show full text]
  • Public Key Cryptography And
    PublicPublic KeyKey CryptographyCryptography andand RSARSA Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-11/ Washington University in St. Louis CSE571S ©2011 Raj Jain 9-1 OverviewOverview 1. Public Key Encryption 2. Symmetric vs. Public-Key 3. RSA Public Key Encryption 4. RSA Key Construction 5. Optimizing Private Key Operations 6. RSA Security These slides are based partly on Lawrie Brown’s slides supplied with William Stallings’s book “Cryptography and Network Security: Principles and Practice,” 5th Ed, 2011. Washington University in St. Louis CSE571S ©2011 Raj Jain 9-2 PublicPublic KeyKey EncryptionEncryption Invented in 1975 by Diffie and Hellman at Stanford Encrypted_Message = Encrypt(Key1, Message) Message = Decrypt(Key2, Encrypted_Message) Key1 Key2 Text Ciphertext Text Keys are interchangeable: Key2 Key1 Text Ciphertext Text One key is made public while the other is kept private Sender knows only public key of the receiver Asymmetric Washington University in St. Louis CSE571S ©2011 Raj Jain 9-3 PublicPublic KeyKey EncryptionEncryption ExampleExample Rivest, Shamir, and Adleman at MIT RSA: Encrypted_Message = m3 mod 187 Message = Encrypted_Message107 mod 187 Key1 = <3,187>, Key2 = <107,187> Message = 5 Encrypted Message = 53 = 125 Message = 125107 mod 187 = 5 = 125(64+32+8+2+1) mod 187 = {(12564 mod 187)(12532 mod 187)... (1252 mod 187)(125 mod 187)} mod 187 Washington University in
    [Show full text]
  • Crypto Wars of the 1990S
    Danielle Kehl, Andi Wilson, and Kevin Bankston DOOMED TO REPEAT HISTORY? LESSONS FROM THE CRYPTO WARS OF THE 1990S CYBERSECURITY June 2015 | INITIATIVE © 2015 NEW AMERICA This report carries a Creative Commons license, which permits non-commercial re-use of New America content when proper attribution is provided. This means you are free to copy, display and distribute New America’s work, or in- clude our content in derivative works, under the following conditions: ATTRIBUTION. NONCOMMERCIAL. SHARE ALIKE. You must clearly attribute the work You may not use this work for If you alter, transform, or build to New America, and provide a link commercial purposes without upon this work, you may distribute back to www.newamerica.org. explicit prior permission from the resulting work only under a New America. license identical to this one. For the full legal code of this Creative Commons license, please visit creativecommons.org. If you have any questions about citing or reusing New America content, please contact us. AUTHORS Danielle Kehl, Senior Policy Analyst, Open Technology Institute Andi Wilson, Program Associate, Open Technology Institute Kevin Bankston, Director, Open Technology Institute ABOUT THE OPEN TECHNOLOGY INSTITUTE ACKNOWLEDGEMENTS The Open Technology Institute at New America is committed to freedom The authors would like to thank and social justice in the digital age. To achieve these goals, it intervenes Hal Abelson, Steven Bellovin, Jerry in traditional policy debates, builds technology, and deploys tools with Berman, Matt Blaze, Alan David- communities. OTI brings together a unique mix of technologists, policy son, Joseph Hall, Lance Hoffman, experts, lawyers, community organizers, and urban planners to examine the Seth Schoen, and Danny Weitzner impacts of technology and policy on people, commerce, and communities.
    [Show full text]
  • NSA's Efforts to Secure Private-Sector Telecommunications Infrastructure
    Under the Radar: NSA’s Efforts to Secure Private-Sector Telecommunications Infrastructure Susan Landau* INTRODUCTION When Google discovered that intruders were accessing certain Gmail ac- counts and stealing intellectual property,1 the company turned to the National Security Agency (NSA) for help in securing its systems. For a company that had faced accusations of violating user privacy, to ask for help from the agency that had been wiretapping Americans without warrants appeared decidedly odd, and Google came under a great deal of criticism. Google had approached a number of federal agencies for help on its problem; press reports focused on the company’s approach to the NSA. Google’s was the sensible approach. Not only was NSA the sole government agency with the necessary expertise to aid the company after its systems had been exploited, it was also the right agency to be doing so. That seems especially ironic in light of the recent revelations by Edward Snowden over the extent of NSA surveillance, including, apparently, Google inter-data-center communications.2 The NSA has always had two functions: the well-known one of signals intelligence, known in the trade as SIGINT, and the lesser known one of communications security or COMSEC. The former became the subject of novels, histories of the agency, and legend. The latter has garnered much less attention. One example of the myriad one could pick is David Kahn’s seminal book on cryptography, The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet.3 It devotes fifty pages to NSA and SIGINT and only ten pages to NSA and COMSEC.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • RSA BSAFE Crypto-C 5.21 FIPS 140-1 Security Policy2.…
    RSA Security, Inc. RSA™ BSAFE® Crypto-C Crypto-C Version 5.2.1 FIPS 140-1 Non-Proprietary Security Policy Level 1 Validation Revision 1.0, May 2001 © Copyright 2001 RSA Security, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents 1 INTRODUCTION.................................................................................................................. 3 1.1 PURPOSE ............................................................................................................................. 3 1.2 REFERENCES ....................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................... 3 2 THE RSA BSAFE PRODUCTS............................................................................................ 5 2.1 THE RSA BSAFE CRYPTO-C TOOLKIT MODULE .............................................................. 5 2.2 MODULE INTERFACES ......................................................................................................... 5 2.3 ROLES AND SERVICES ......................................................................................................... 6 2.4 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................................ 7 2.4.1 Protocol Support........................................................................................................
    [Show full text]
  • Notices Openssl/Open SSL Project
    Notices The following notices pertain to this software license. OpenSSL/Open SSL Project This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]). License Issues The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected]. OpenSSL License: Copyright © 1998-2007 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)”. 4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]