Challenging RSA Cryptosystem Implementations
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Alcatel-Lucent Security Advisory Sa0xx
Alcatel-Lucent Security Advisory No. SA0053 Ed. 04 Information about Poodle vulnerability Summary POODLE stands for Padding Oracle On Downgraded Legacy Encryption. The POODLE has been reported in October 14th 2014 allowing a man-in-the-middle attacker to decrypt ciphertext via a padding oracle side-channel attack. The severity is not considered as the same for Heartbleed and/or bash shellshock vulnerabilities. The official risk is currently rated Medium. The classification levels are: Very High, High, Medium, and Low. The SSLv3 protocol is only impacted while TLSv1.0 and TLSv1.2 are not. This vulnerability is identified CVE- 2014-3566. Alcatel-Lucent Enterprise voice products using protocol SSLv3 are concerned by this security alert. Openssl versions concerned by the vulnerability: OpenSSL 1.0.1 through 1.0.1i (inclusive) OpenSSL 1.0.0 through 1.0.0n (inclusive) OpenSSL 0.9.8 through 0.9.8zb (inclusive) The Alcatel-Lucent Enterprise Security Team is currently investigating implications of this security flaw and working on a corrective measure, for OpenTouch 2.1.1 planned in Q4 2015, to prevent using SSLv3 that must be considered as vulnerable. This note is for informational purpose about the padding-oracle attack identified as “POODLE”. References CVE-2014-3566 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 Advisory severity CVSS Base score : 4.3 (MEDIUM) - AV:N/AC:M/Au:N/C:P/I:N/A:N https://www.openssl.org/news/secadv_20141015.txt https://www.openssl.org/~bodo/ssl-poodle.pdf Description of the vulnerabilities Information about Poodle vulnerability (CVE-2014-3566). -
Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities
Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget and Juraj Somorovsky, Ruhr University Bochum; Nimrod Aviram, Tel Aviv University; Craig Young, Tripwire VERT; Janis Fliegenschmidt and Jörg Schwenk, Ruhr University Bochum; Yuval Shavitt, Tel Aviv University https://www.usenix.org/conference/usenixsecurity19/presentation/merget This paper is included in the Proceedings of the 28th USENIX Security Symposium. August 14–16, 2019 • Santa Clara, CA, USA 978-1-939133-06-9 Open access to the Proceedings of the 28th USENIX Security Symposium is sponsored by USENIX. Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget1, Juraj Somorovsky1, Nimrod Aviram2, Craig Young3, Janis Fliegenschmidt1, Jörg Schwenk1, and Yuval Shavitt2 1Ruhr University Bochum 2Department of Electrical Engineering, Tel Aviv University 3Tripwire VERT Abstract the encryption key. The attack requires a server that decrypts a message and responds with 1 or 0 based on the message va- The TLS protocol provides encryption, data integrity, and lidity. This behavior essentially provides the attacker with a authentication on the modern Internet. Despite the protocol’s cryptographic oracle which can be used to mount an adaptive importance, currently-deployed TLS versions use obsolete chosen-ciphertext attack. The attacker exploits this behavior cryptographic algorithms which have been broken using var- to decrypt messages by executing adaptive queries.Vaudenay ious attacks. One prominent class of such attacks is CBC exploited a specific form of vulnerable behavior, where im- padding oracle attacks. These attacks allow an adversary to plementations validate the CBC padding structure and re- decrypt TLS traffic by observing different server behaviors spond with 1 or 0 accordingly. -
Technical Report RHUL–ISG–2019–1 27 March 2019
20 years of Bleichenbacher attacks Gage Boyle Technical Report RHUL–ISG–2019–1 27 March 2019 Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom Student Number: 100866673 Gage, Boyle 20 Years of Bleichenbacher Attacks Supervisor: Kenny Paterson Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London. I declare that this assignment is all my own work and that I have acknowledged all quotations from published or unpublished work of other people. I also declare that I have read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences, and in accordance with these regulations I submit this project report as my own work. Signature: Date: Acknowledgements I would first like to thank my project supervisor, Kenny Paterson. This project would not have been possible without his continuous encouragement to push the boundaries of my knowledge, and I am grateful for the commitment and expertise that he has provided throughout. Secondly, I would like to thank Nimrod Aviram for his invaluable advice, particularly with respect to algorithm implementation and understanding the finer details of this project. Further thanks should go to Raja Naeem Akram, Oliver Kunz and David Morrison for taking the time to teach me Python and how to run my source code on an Ubuntu server. I am grateful for the time that David Stranack, Thomas Bingham and James Boyle have spent proof reading this project, and for the continuous support from my part- ner, Lisa Moxham. -
TLS Deep Dive
12/9/17 TLS Deep Dive Website Security & More Joe Pranevich December 5, 2017 Today’s Session – Overview of TLS – Connection Establishment – Testing Tools – Recent Security Issues 1 12/9/17 What is SSL/TLS? – Core internet protocols (IP, TCP, HTTP) were designed without default security – SSL was invented in 1995 by Netscape to support encryption of web traffic for ecommerce and other uses. – SSL/TLS sits above TCP. It can be used to encrypt many protocols, but mostly used for HTTP. – Over two decades, SSL has been improved (with vulnerabilities discovered in older versions). The name was changed to TLS in 1999. SSL & TLS Timeline Protocol Released Notes SSLv2 1995 Vulnerable, depreciated in 2011 SSLv3 1996 Vulnerable, depreciated in 2015 TLS 1.0 1999 At risk, no longer permitted by PCI TLS 1.1 2006 TLS 1.2 2008 TLS 1.3 TBD Internet Draft 2 12/9/17 But Wait, There’s More! – TLS supports dozens of different encryption methods, compression methods, hashing functions, and other details. – Clients and servers select from a menu of these options to negotiate the best security (more on that later) – Most of these options have their own security histories, some have been deprecated, etc. Key Concepts – Shared Key Cryptography (Symmertric) – Public/Private Key Cryptography (Asymmetric) – Hashing 3 12/9/17 Connection Establishment – TLS Handshake – Cipher negotiation – Certificate Validation – Device Compatibility TLS Handshake – Part One – Client sends a “hello” message saying that they want TLS. – It includes TLS version, ciphers it supports, and other details – Server sends a “hello” message back. – It selects the most secure matching TLS version and ciphers – Connection will fail if client and server cannot agree on protocols and ciphers 4 12/9/17 Client Devices Have Different Capabilities As Do Servers & Load Balancers 5 12/9/17 We Care About The Intersection Backwards Compatibility Warning! – Web browsers and operating systems get updated frequently; you can usually rely on web users having a recent TLS stack when they connect to you. -
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. -
Download a PDF Version of the 2017 Annual Review
Front Back Cover for Avisan.qxp_Layout 1 11/15/17 1:27 PM Page 1 Secure Technology Alliance 191 Clarksville Road Princeton Junction, New Jersey 08550 Annual Review 2017 Alliance A Secure Publication Technology 7 Volume www.securetechalliance.org Annual Review 2017 SCA-ad 2017 resized.indd 1 10/30/2017 10:40:22 AM EXECUTIVE DIRECTOR’S LETTER: A MESSAGE FROM RANDY VANDERHOOF Delivering Value to a Diverse Market Thank you for taking the time to read the 2017 Annual Review. This publication captures the best aspects of the membership experience for 2017 that hundreds of individual members and their organizations helped to provide. This year was especially sig- nificant, as the organization expanded its mission beyond smart cards and was re-branded as the Secure Technology Alliance. The new name and scope allows the Alliance to include embedded chip technology, hardware and software, and the future of digital security in all forms. The vast number of deliverables and member-driven activities recorded in the publication illustrates the diversity of the markets we serve and the commitment of all the industry professionals who contribute their knowledge and leadership toward expanding the market for smart card and related secure chip technologies. CHANGE COMES WITH NEW OPPORTUNITIES The decision to expand the mission and rebrand the organization was driven THE DECISION TO EXPAND by the changes in the secure chip industry, mostly from mobile technol- ogy and the growth of Internet-connected devices. This does not mean the THE MISSION AND REBRAND market for smart cards has disappeared. In fact, over the last few years, the THE ORGANIZATION WAS U.S. -
TLS Attacks & DNS Security
IAIK TLS Attacks & DNS Security Information Security 2019 Johannes Feichtner [email protected] IAIK Outline TCP / IP Model ● Browser Issues Application SSLStrip Transport MITM Attack revisited Network Link layer ● PKI Attacks (Ethernet, WLAN, LTE…) Weaknesses HTTP TLS / SSL FLAME FTP DNS Telnet SSH ● Implementation Attacks ... ● Protocol Attacks ● DNS Security IAIK Review: TLS Services All applications running TLS are provided with three essential services Authentication HTTPS FTPS Verify identity of client and server SMTPS ... Data Integrity Detect message tampering and forgery, TLS e.g. malicious Man-in-the-middle TCP IP Encryption Ensure privacy of exchanged communication Note: Technically, not all services are required to be used Can raise risk for security issues! IAIK Review: TLS Handshake RFC 5246 = Establish parameters for cryptographically secure data channel Full handshake Client Server scenario! Optional: ClientHello 1 Only with ServerHello Client TLS! Certificate 2 ServerKeyExchange Certificate CertificateRequest ClientKeyExchange ServerHelloDone CertificateVerify 3 ChangeCipherSpec Finished ChangeCipherSpec 4 Finished Application Data Application Data IAIK Review: Certificates Source: http://goo.gl/4qYsPz ● Certificate Authority (CA) = Third party, trusted by both the subject (owner) of the certificate and the party (site) relying upon the certificate ● Browsers ship with set of > 130 trust stores (root CAs) IAIK Browser Issues Overview Focus: Relationship between TLS and HTTP Problem? ● Attacker wants to access encrypted data ● Browsers also have to deal with legacy websites Enforcing max. security level would „break“ connectivity to many sites Attack Vectors ● SSLStrip ● MITM Attack …and somehow related: Cookie Stealing due to absent „Secure“ flag… IAIK Review: ARP Poisoning How? Attacker a) Join WLAN, ● Sniff data start ARP Poisoning ● Manipulate data b) Create own AP ● Attack HTTPS connections E.g. -
Yet Another Padding Oracle in Openssl CBC Ciphersuites
Yet Another Padding Oracle in OpenSSL CBC Ciphersuites presented by Raphael Finkel based on https://blog.cloudflare.com/ yet-another-padding-oracle-in-openssl-cbc-ciphersuites/ Keeping Current, September 5, 2018 The Cryptographic Doom Principle I reference: https://moxie.org/blog/ the-cryptographic-doom-principle/ by Moxie Marlinspike I If you have to perform any cryptographic operation before verifying the MAC (message authentication code) on a message you’ve received, it will somehow inevitably lead to doom. I MAC is a cryptographic digest based on a secret key shared by Alice and Bob. I Proper use of MAC: Encrypt Then Authenticate (Encrypt-then-MAC, EtA; used in IPsec) I Alice sends to Bob: E(P) || MAC(E(P)) I Detail: E(P) also includes such information as the initialization vector and the encryption algorithm; both are then covered by MAC(). I Bob first verifies MAC(E(P)), satisfying the principle. If that test passes, Bob decrypts P. I Good: Verifies integrity of E(P), therefore it also verifies integrity of P. I Good: MAC(E(P)) provides no information about P. Authenticate and encrypt (Encrypt-and-MAC, E&A; used in SSH) I Alice sends to Bob: E(P) || MAC(P) I Bob must first decrypt E(P) to get P, then confirm MAC(P), violating the principle. I Good: verifies integrity of P. I Not good: I May theoretically reveal information about P in MAC(P). I No integrity check on E(P). I Bad: vulnerable to chosen-ciphertext attacks on E. I Man-in-the-middle Morton can try various versions of E(P), noting whether Bob gets as far as trying to verify MAC(P). -
Safe and Secure Model-Driven Design for Embedded Systems Letitia Li
Safe and secure model-driven design for embedded systems Letitia Li To cite this version: Letitia Li. Safe and secure model-driven design for embedded systems. Embedded Systems. Université Paris-Saclay, 2018. English. NNT : 2018SACLT002. tel-01894734 HAL Id: tel-01894734 https://pastel.archives-ouvertes.fr/tel-01894734 Submitted on 12 Oct 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Approche Orientee´ Modeles` pour la Suretˆ e´ et la Securit´ e´ des Systemes` Embarques´ These` de doctorat de l’Universite´ Paris-Saclay prepar´ ee´ a` Telecom ParisTech Ecole doctorale n◦580 Denomination´ (STIC) NNT : 2018SACLT002 Specialit´ e´ de doctorat: Informatique These` present´ ee´ et soutenue a` Biot, le 3 septembre` 2018, par LETITIA W. LI Composition du Jury : Prof. Philippe Collet Professeur, Universite´ Coteˆ d’Azur President´ Prof. Guy Gogniat Professeur, Universite´ de Bretagne Sud Rapporteur Prof. Maritta Heisel Professeur, University Duisburg-Essen Rapporteur Prof. Jean-Luc Danger Professeur, Telecom ParisTech Examinateur Dr. Patricia Guitton -
ECE 435 – Network Engineering Lecture 4
ECE 435 { Network Engineering Lecture 4 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 13 September 2018 Announcements • HW#1 was due. • HW#2 will be posted. Write a mini webserver. • Cybersecurity club Linux Security Lab on Saturday 1 WWW wrapup 2 What if Server Overloaded? • Slashdot effect (modern: HackerNews?) • caching/proxy { squid • Content Delivery Network { akami • Server farms 3 Security • SSL { Secure Socket Layer • Replaced by TLS (Transport Layer Security) • Port 443 for https • Public key encryption. 4 Setting Up a Web-server • Apache • Easy to do, more difficult to secure 5 Web Seach • Web-bots index the web. robots.txt file • Altavista, Hotbot, Excite, Inktomi, etc. • Curated search like Yahoo (people organize links rather than automatically search) • Google (1996 some machine in Stanford, 1997-1998) • MSN search 1999, rebranded Microsoft Bing 2009 6 Remote Connections 7 telnet/rlogin/rsh/ssh • telnet { login to remote system (tcp port 23) everything (including passwords) sent in plain text • rsh/rlogin { remote shell, remote login. (tcp port 514) Didn't even need password, could configure to let you run commands on remote machine. Security based if you had same username on both machines, assumption was getting root on a UNIX machine and connected to Ethernet was expensive/difficult 8 SSH secure shell • tcp port 22 • can login, run commands, tunnel tcp/ip, tunnel X11, file transfer (scp, sftp) • Large number of RFCs • Version 1: 1995, originally freeware but became private • Version 2: 2005, openBSD based on last free version • For security reasons there's a push to drop Version 1 • uses public-key cryptography • transport layer: arranges initial key exchange, server 9 authentication, key re-exchange • user authentication layer: can have password, or can set up keys to allow passwordless, DSA or RSA key pairs • connection layer: set up channels • lots of encryption types supported, old ones being obsoleted as found wanting • Various ssh servers/clients. -
Zerohack Zer0pwn Youranonnews Yevgeniy Anikin Yes Men
Zerohack Zer0Pwn YourAnonNews Yevgeniy Anikin Yes Men YamaTough Xtreme x-Leader xenu xen0nymous www.oem.com.mx www.nytimes.com/pages/world/asia/index.html www.informador.com.mx www.futuregov.asia www.cronica.com.mx www.asiapacificsecuritymagazine.com Worm Wolfy Withdrawal* WillyFoReal Wikileaks IRC 88.80.16.13/9999 IRC Channel WikiLeaks WiiSpellWhy whitekidney Wells Fargo weed WallRoad w0rmware Vulnerability Vladislav Khorokhorin Visa Inc. Virus Virgin Islands "Viewpointe Archive Services, LLC" Versability Verizon Venezuela Vegas Vatican City USB US Trust US Bankcorp Uruguay Uran0n unusedcrayon United Kingdom UnicormCr3w unfittoprint unelected.org UndisclosedAnon Ukraine UGNazi ua_musti_1905 U.S. Bankcorp TYLER Turkey trosec113 Trojan Horse Trojan Trivette TriCk Tribalzer0 Transnistria transaction Traitor traffic court Tradecraft Trade Secrets "Total System Services, Inc." Topiary Top Secret Tom Stracener TibitXimer Thumb Drive Thomson Reuters TheWikiBoat thepeoplescause the_infecti0n The Unknowns The UnderTaker The Syrian electronic army The Jokerhack Thailand ThaCosmo th3j35t3r testeux1 TEST Telecomix TehWongZ Teddy Bigglesworth TeaMp0isoN TeamHav0k Team Ghost Shell Team Digi7al tdl4 taxes TARP tango down Tampa Tammy Shapiro Taiwan Tabu T0x1c t0wN T.A.R.P. Syrian Electronic Army syndiv Symantec Corporation Switzerland Swingers Club SWIFT Sweden Swan SwaggSec Swagg Security "SunGard Data Systems, Inc." Stuxnet Stringer Streamroller Stole* Sterlok SteelAnne st0rm SQLi Spyware Spying Spydevilz Spy Camera Sposed Spook Spoofing Splendide -
It-Säkerhet - Examensarbete
IT-SÄKERHET - EXAMENSARBETE Största IT-säkerhetshoten mot svenska företag och organisationer idag, samt kontemporära metoder och verktyg för bekämpning av dessa IT-säkerhetshot. DEN 29 MARS 2016 BENJAMIN LUNDSTRÖM Examensarbete i Nät- & kommunikationsteknik, Umeå universitet. Löpnummer EL1609. BENJAMIN LUNDSTRÖM 16-03-29 IT-SÄKERHET - EXAMENSARBETE Sammanfattning Olika former av IT-relaterade hot har förekommit sedan internets födelse. Inledningsvis var de harmlösa humoristiska program som över tiden utvecklades till kriminella verktyg med ekonomiska syften. Elakartad programkod benämns under samlingsnamnet Malware. En angripare besitter idag ett stort antal metoder för otillåten tillgång till system, neka legitima användare tillgång till system eller på ett stort antal sätt bedriva kriminell verksamhet av ekonomisk karaktär. Skydds- och bekämpningsmetoderna innefattar brandväggar, olika analys-, detektions- och preventionssystem (IDS/IPS) och kryptering. Men för att komma tillrätta med IT-hoten fullt ut krävs också säkerhetsutbildning och incidenthantering som sker via incidentplanering, rapporter, dokumentation, backup och informationsklassning. Kontemporära IT-säkerhetshot av betydande art belyses i rapporten. Stuxnet (2009), som angrep Irans kärnvapenforskning. Flamer (2011), ett cybervapen vars syfte är spårlös informationsinhämtning. BlackEnergy (2015) och angreppet mot elförsörjningen i Ukraina. DDoS- attacken mot Svenska medier behandlas liksom Petya (2016) som är nya generationens Ransomeware. Det är vitalt för företag och organisationer att skydda sin viktigaste tillgång, informationen. Både mot cyberkriminella element i rent finansiellt syfte men i tilltagande grad också mot olika cybervapen och möjligtvis också mot cyberterrorism. Abstract A number of IT-related threats have emerged since the birth of internet. In the beginning they were harmless but over time they developed into fearsome criminal tools for economic purposes.