DOCSLIB.ORG

Assurance Activity Report (MDFPP31/WLANCEP10) for Google Pixel Phones on Android 11.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Assurance Activity Report (MDFPP31/WLANCEP10) for Google Pixel Phones on Android 11.0 www.GossamerSec.com Assurance Activity Report (MDFPP31/WLANCEP10) for Google Pixel Phones on Android 11.0 Version 0.4 02/04/2021 Prepared by: Gossamer Security Solutions Accredited Security Testing Laboratory – Common Criteria Testing Catonsville, MD 21228 Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Document: AAR-VID11124 © 2020 Gossamer Security Solutions, Inc. All rights reserved. Version 0.4, 02/04/2021 REVISION HISTORY Revision Date Authors Summary Version 0.1 12/11/20 Tammy Compton Initial draft Austin Kimbrell Version 0.2 01/21/21 Austin Kimbrell Address comments Version 0.3 01/29/21 Austin Kimbrell Address comments Version 0.4 02/04/21 Austin Kimbrell Address comments The TOE Evaluation was Sponsored by: Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 Evaluation Personnel: Justin Bettencourt Tammy Compton Austin Kimbrell John Messiha Raymond Smoley Gossamer Security Solutions, Inc. Catonsville, MD Common Criteria Versions: Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 5, April 2017 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 5, April 2017 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1, Revision 5, April 2017 Common Evaluation Methodology Versions: Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, April 2017 GSS CCT Assurance Activity Report Page 2 of 182 © 2020 Gossamer Security Solutions, Inc. Document: AAR-VID11124 All rights reserved. Version 0.4, 02/04/2021 TABLE OF CONTENTS 1. Introduction ........................................................................................................................................................... 7 1.1 Device Equivalence ...................................................................................................................................... 7 1.2 CAVP Algorithms .......................................................................................................................................... 7 2. Protection Profile SFR Assurance Activities ......................................................................................................... 10 2.1 Security audit (FAU) ................................................................................................................................... 10 2.1.1 Audit Data Generation (MDFPP31:FAU_GEN.1) ................................................................................... 10 2.1.2 Audit Storage Protection (MDFPP31:FAU_STG.1) ................................................................................ 12 2.1.3 Prevention of Audit Data Loss (MDFPP31:FAU_STG.4) ........................................................................ 13 2.2 Cryptographic support (FCS) ...................................................................................................................... 14 2.2.1 Cryptographic key generation (MDFPP31:FCS_CKM.1) ........................................................................ 14 2.2.2 Cryptographic Key Generation (Symmetric Keys for WPA2 Connections) (WLANCEP10:FCS_CKM.1/WLAN) ....................................................................................................................... 18 2.2.3 Cryptographic key establishment (MDFPP31:FCS_CKM.2(1)) .............................................................. 20 2.2.4 Cryptographic key establishment (While device is locked) (MDFPP31:FCS_CKM.2(2))........................ 24 2.2.5 Cryptographic Key Distribution (GTK) (WLANCEP10:FCS_CKM.2/WLAN)............................................. 25 2.2.6 Extended: Cryptographic Key Support (MDFPP31:FCS_CKM_EXT.1) ................................................... 26 2.2.7 Extended: Cryptographic Key Random Generation (MDFPP31:FCS_CKM_EXT.2) ................................ 28 2.2.8 Extended: Cryptographic Key Generation (MDFPP31:FCS_CKM_EXT.3) .............................................. 34 2.2.9 Extended: Key Destruction (MDFPP31:FCS_CKM_EXT.4) ..................................................................... 39 2.2.10 Extended: TSF Wipe (MDFPP31:FCS_CKM_EXT.5) ........................................................................... 42 2.2.11 Extended: Salt Generation (MDFPP31:FCS_CKM_EXT.6) ................................................................. 43 2.2.12 Cryptographic operation (MDFPP31:FCS_COP.1(1)) ........................................................................ 44 2.2.13 Cryptographic operation (MDFPP31:FCS_COP.1(2)) ........................................................................ 49 2.2.14 Cryptographic operation (MDFPP31:FCS_COP.1(3)) ........................................................................ 51 2.2.15 Cryptographic operation (MDFPP31:FCS_COP.1(4)) ........................................................................ 52 2.2.16 Cryptographic operation (MDFPP31:FCS_COP.1(5)) ........................................................................ 53 2.2.17 Extended: HTTPS Protocol (MDFPP31:FCS_HTTPS_EXT.1) ............................................................... 54 2.2.18 Extended: Initialization Vector Generation (MDFPP31:FCS_IV_EXT.1) ............................................ 56 2.2.19 Extended: Cryptographic Operation (Random Bit Generation) (MDFPP31:FCS_RBG_EXT.1) .......... 56 2.2.20 Extended: Cryptographic Algorithm Services (MDFPP31:FCS_SRV_EXT.1) ...................................... 59 GSS CCT Assurance Activity Report Page 3 of 182 © 2020 Gossamer Security Solutions, Inc. Document: AAR-VID11124 All rights reserved. Version 0.4, 02/04/2021 2.2.21 Extended: Cryptographic Algorithm Services (MDFPP31:FCS_SRV_EXT.2) ...................................... 59 2.2.22 Extended: Cryptographic Key Storage (MDFPP31:FCS_STG_EXT.1) ................................................. 60 2.2.23 Extended: Encrypted Cryptographic Key Storage (MDFPP31:FCS_STG_EXT.2) ................................ 63 2.2.24 Extended: Integrity of encrypted key storage (MDFPP31:FCS_STG_EXT.3) ..................................... 64 2.2.25 Extended: TLS Protocol (MDFPP31:FCS_TLSC_EXT.1) ...................................................................... 65 2.2.26 Extensible Authentication Protocol-Transport Layer Security (WLANCEP10:FCS_TLSC_EXT.1/WLAN)................................................................................................................ 71 2.2.27 Extended: TLS Protocol (MDFPP31:FCS_TLSC_EXT.2) ...................................................................... 74 2.2.28 TLS Client Protocol (WLANCEP10:FCS_TLSC_EXT.2/WLAN) ............................................................. 75 2.3 User data protection (FDP) ........................................................................................................................ 76 2.3.1 Extended: Security access control (MDFPP31:FDP_ACF_EXT.1) ........................................................... 76 2.3.2 Extended: Security access control (MDFPP31:FDP_ACF_EXT.2) ........................................................... 82 2.3.3 Extended: Protected Data Encryption (MDFPP31:FDP_DAR_EXT.1) .................................................... 82 2.3.4 Extended: Sensitive Data Encryption (MDFPP31:FDP_DAR_EXT.2) ...................................................... 84 2.3.5 Extended: Subset information flow control (MDFPP31:FDP_IFC_EXT.1) ............................................. 86 2.3.6 Extended: Storage of Critical Biometric Parameters (MDFPP31:FDP_PBA_EXT.1) ............................... 89 2.3.7 Extended: User Data Storage (MDFPP31:FDP_STG_EXT.1) .................................................................. 89 2.3.8 Extended: Inter-TSF user data transfer protection (MDFPP31:FDP_UPC_EXT.1) ................................. 90 2.4 Identification and authentication (FIA) ...................................................................................................... 92 2.4.1 Extended: Authentication failure handling (MDFPP31:FIA_AFL_EXT.1) ............................................... 93 2.4.2 Extended: Bluetooth User Authorization (MDFPP31:FIA_BLT_EXT.1) .................................................. 96 2.4.3 Extended: Bluetooth Mutual Authentication (MDFPP31:FIA_BLT_EXT.2)............................................ 97 2.4.4 Extended: Rejection of Duplicate Bluetooth Connections (MDFPP31:FIA_BLT_EXT.3) ........................ 98 2.4.5 Extended: Secure Simple Pairing (MDFPP31:FIA_BLT_EXT.4) .............................................................. 99 2.4.6 Extended: Bluetooth User Authorization (MDFPP31:FIA_BLT_EXT.6) ................................................ 100 2.4.7 Extended: Accuracy of Biometric Authentication (MDFPP31:FIA_BMG_EXT.1/Fingerprint) ............. 101 2.4.8 Extended: Accuracy of Biometric Authentication (MDFPP31:FIA_BMG_EXT.1/Face) ........................ 103 2.4.9 Port Access Entity Authentication (WLANCEP10:FIA_PAE_EXT.1) ...................................................... 104 2.4.10 Extended: Password Management (MDFPP31:FIA_PMG_EXT.1) ................................................... 105 2.4.11 Extended: Authentication Throttling (MDFPP31:FIA_TRT_EXT.1) .................................................. 106 2.4.12 Multiple Authentication Mechanisms (MDFPP31:FIA_UAU.5) .....................................................
Load more

Recommended publications
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
    [Show full text]
  • Securecrt 7.3.6 Crack for Mac >>>
    Securecrt 7.3.6 Crack For Mac >>> http://shurll.com/77o35 1 / 5 2 / 5 hash,,47850D6A1C717CEC4534B14525ED9BF2292DD905,,... VanDyke,,SecureCRT,,and,,SecureFX,,7 .3.6,,[Mac,,Os,,X],,[MAC599],,DOWNLOAD,,TORRENTSecureCRT,,for,,Mac,,OS,,X,,7.1... VanDyke,,Secu reCRT,,and,,SecureFX,,7.3.6,,[Mac,,Os,,X].torrent,,내부,,파일,,..Turn,,,your,,,computer,,,into,,,a,,,terminal,, ,server,,,using,,,Serial,,,to,,,Ethernet,,,Converter,,,with,,,its,,,amazing,,,capability,,,to,,,share,,,serial,,, devices,,,in,,,... Free,,,Download,,,SecureCRT,,,for,,,Mac,,,8.1.3,,,Build,,,1382,,,-,,,A,,,fully-featured,,,te rminal,,,emulator,,,as,,,well,,,as,,,a,,,SSH,,,and,,,Telnet,,,client,,,with,,,advanced,,,session,,,mana... Do wnload,,,VanDyke,,,SecureCRT,,,and,,,SecureFX,,,7.3.6,,,[Mac,,,Os,,,X],,,[MAC599],,,torrent,,,or,,,any,, ,other,,,torrent,,,from,,,Mac,,,category. SecureCRT®,,,7.3.6.963,,,for,,,MAC,,,|,,,40.7MbUsers,,,with,,,PCs,,,installed,,,with,,,Windows,,,8. Secu reCRT,,,provides,,,rock-solid,,,terminal,,,emulation,,,for,,,computing,,,professionals,,,,raising,,,product ivity,,,with,,,advanced,,,session,,,management,,,and,,,a,,,host,,,of,,,ways,,,to,,,save SecureCRT,,,for,,, Mac,,,,free,,,and,,,safe,,,downloadSecureCRT,,,supports,,,SSH2,,,,SSH1,,,,Telnet,,,,Telnet/SSL,,,,Serial, ,,,and,,,other,,,protocols..It,,,has,,,been,,,designed,,,to,,,be,,,used,,,during,,,the,,,high,,,stress,,,produc tion,,,... Torrentz,,,-,,,Fast,,,and,,,convenient,,,Torrents,,,Search,,,EngineApowersoft,,Screen,,Capture, ,Pro,,1.3.1,,InclTurn,,your,,computer,,into,,a,,terminal,,server,,using,,Serial,,to,,Ethernet,,Converter,,
    [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]
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
    [Show full text]
  • Feature List Secure Shell
    Feature List Secure Shell SSH1 and SSH2 support Both SSH1 and SSH2 are supported in a single client, providing the maximum in flexibility when connecting to a range of remote servers. User authentication SecureCRT supports Password, Public Key (RSA, DSA, and X.509 including Smart Cards), Kerberos v5 (via GSSAPI), and Keyboard Interactive when connecting to SSH2 servers. For SSH1 servers, Password, Public Key, and TIS authentications are supported. Public Key Assistant Support for Public Key Assistant makes uploading public keys to an SSH2 server simple and safe for end users. Support for GSSAPI secured key Mechanisms supported depend on GSSAPI provider. exchange SFTP in a tab You can open an SFTP tab to the same SSH2 session without having to re-authenticate to perform file transfer operations using an interactive, text-based SFTP utility. Encryption ciphers: Strong The maximum 2048 bits length of DSA keys under SSH2 provides strong encryption. SecureCRT supports AES- encryption 128, AES-192, AES-256, Twofish, Blowfish, 3DES, and RC4 when connecting to SSH2 servers. For SSH1 servers, Blowfish, DES, 3DES, and RC4 are supported. Password and passphrase SSH2 session passwords and passphrases can be cached, letting SecureCRT and SecureFX share passwords and caching passphrases while either application or the Activator utility is running. Port forwarding Tunnel common TCP/IP protocols (for example, POP3, IMAP4, HTTP, SMTP) via SecureCRT to a remote Secure Shell server using a single, secure, multiplexed connection. Port forwarding configuration has been integrated into the tree-based Session Options dialog allowing easier configuration for securing TCP/IP application data. Dynamic port forwarding Dynamic port forwarding simplifies how TCP/IP application data is routed through the Secure Shell connection.
    [Show full text]
  • A Technical Comparison of Ipsec and SSL
    A Technical Comparison of IPSec and SSL y Ab delNasir Alshamsi Takamichi Saito Tokyo University of Technology Abstract p osed but the most famous secure and widely de ployed are IPSec IP Security and SSL Secure So cket Layer IPSec IP Security and SSL SecureSocket Layer In this pap er we will provide a technical comparison have been the most robust and most potential tools of IPSec and SSL the similarities and the dierences available for securing communications over the Inter of the cryptographic prop erties The results of per net Both IPSec and SSL have advantages and short formance are based on comparing FreeSWAN as comings Yet no paper has been found comparing the IPSec and Stunnel as SSL two protocols in terms of characteristic and functional ity Our objective is to present an analysis of security and performancepr operties for IPSec and SSL IPSec IPSec is an IP layer proto col that enables the Intro duction sending and receiving of cryptographically protected packets of any kind TCPUDPICMPetc without any provides two kinds of crypto mo dication IPSec Securing data over the network is hard and compli graphic services Based on necessity IPSec can provide cated issue while the threat of data mo dication and condentiality and authenticity or it can provide data interruption is rising The goal of network security authenticity only is to provide condentiality integrity and authenticity Condentiality is keeping the data secret from the ESP Encapsulated SecurityPayload unintended listeners on the network Integrity is en suring
    [Show full text]
  • Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D
    Main Points • Applying last week’s lectures in practice • Creating Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D. Joseph – VPN: Virtual Private Network September 26, 2005 September 26, 2005 CS161 Fall 2005 2 Joseph/Tygar/Vazirani/Wagner What is a Secure Channel? Plaintext Plaintext Creating Secure Channels Encryption / Internet Encryption / • Authentication and Data Integrity Decryption Decryption Ciphertext and MAC – Use Public Key Infrastructure or third-party server to authenticate each end to the other • A stream with these security requirements: – Add Message Authentication Code for – Authentication integrity • Ensures sender and receiver are who they claim to be – Confidentiality • Confidentiality • Ensures that data is read only by authorized users – Data integrity – Exchange session key for encrypt/decrypt ops • Ensures that data is not changed from source to destination • Bulk data transfer – Non-repudiation (not discussed today) • Ensures that sender can’t deny message and rcvr can’t deny msg • Key Distribution and Segmentation September 26, 2005 CS161 Fall 2005 3 September 26, 2005 CS161 Fall 2005 4 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Symmetric Key-based Symmetric Key-based Secure Channel Secure Channel Alice Bob • Sender (A) and receiver (B) share secret keys KABencrypt KABencrypt – One key for A è B confidentiality KABauth KABauth – One for A è B authentication/integrity Message MAC Compare? Message – Each message
    [Show full text]
  • Plaintext-Recovery Attacks Against Datagram TLS
    Plaintext-Recovery Attacks Against Datagram TLS Nadhem J. AlFardan and Kenneth G. Paterson∗ Information Security Group Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK fNadhem.Alfardan.2009, [email protected] Abstract GnuTLS2. Both of these provide source toolkits that imple- ment TLS and DTLS as well as being general purpose cryp- The Datagram Transport Layer Security (DTLS) proto- tographic libraries that software developers can use. The col provides confidentiality and integrity of data exchanged first release of OpenSSL to implement DTLS was 0.9.8. between a client and a server. We describe an efficient and Since its release, DTLS has become a mainstream proto- full plaintext recovery attack against the OpenSSL imple- col in OpenSSL. There are also a number of commercial mentation of DTLS, and a partial plaintext recovery attack products that have taken advantage of DTLS. For example, against the GnuTLS implementation of DTLS. The attack DTLS is used to secure Virtual Private Networks (VPNs)3;4 against the OpenSSL implementation is a variant of Vaude- and wireless traffic5. Platforms such as Microsoft Windows, nay’s padding oracle attack and exploits small timing differ- Microsoft .NET and Linux can also make use of DTLS6. ences arising during the cryptographic processing of DTLS In addition, the number of RFC documents that are be- packets. It would have been prevented if the OpenSSL im- ing published on DTLS is increasing. Recent examples in- plementation had been in accordance with the DTLS RFC. clude RFC 5415 [1], RFC 5953 [8] and RFC 6012 [13]. A In contrast, the GnuTLS implementation does follow the new version of DTLS is currently under development in the DTLS RFC closely, but is still vulnerable to attack.
    [Show full text]
  • Prying Open Pandora's Box: KCI Attacks Against
    Prying open Pandora’s box: KCI attacks against TLS Clemens Hlauschek, Markus Gruber, Florian Fankhauser, Christian Schanes RISE – Research Industrial Systems Engineering GmbH {clemens.hlauschek, markus.gruber, florian.fankhauser, christian.schanes}@rise-world.com Abstract and implementations of the protocol: their utility is ex- tremely limited, their raison d’ˆetre is practically nil, and Protection of Internet communication is becoming more the existence of these insecure key agreement options common in many products, as the demand for privacy only adds to the arsenal of attack vectors against cryp- in an age of state-level adversaries and crime syndi- tographically secured communication on the Internet. cates is steadily increasing. The industry standard for doing this is TLS. The TLS protocol supports a multi- 1 Introduction tude of key agreement and authentication options which provide various different security guarantees. Recent at- The TLS protocol [1, 2, 3] is probably the most tacks showed that this plethora of cryptographic options widely used cryptographic protocol on the Internet. in TLS (including long forgotten government backdoors, It is designed to secure the communication between which have been cunningly inserted via export restric- client/server applications against eavesdropping, tamper- tion laws) is a Pandora’s box, waiting to be pried open by ing, and message forgery, and it also provides additional, heinous computer whizzes. Novel attacks lay hidden in optional security properties such as client authentica- plainsight. Parts of TLS areso oldthat theirfoul smell of tion. TLS is an historically grown giant: its predecessor, rot cannot be easily distinguished from the flowery smell SSL [4,5], was developed more than 20 years ago.
    [Show full text]
  • Secure Configuration and Management of Linux Systems
    Secure Configuration and Management of Linux Systems using a Network Service Orchestrator Vijay Satti A Thesis in The Department of Concordia Institute for Information Systems Engineering Presented in Partial Fulfillment of the Requirements for the Degree of Master of Applied Science at Concordia University Montréal, Québec, Canada May 2019 c Vijay Satti, 2019 CONCORDIA UNIVERSITY School of Graduate Studies This is to certify that the thesis prepared By: Vijay Satti Entitled: Secure Configuration and Management of Linux Systems using a Network Service Orchestrator and submitted in partial fulfillment of the requirements for the degree of Master of Applied Science complies with the regulations of this University and meets the accepted standards with respect to originality and quality. Signed by the Final Examining Committee: Chair Dr. Walter Lucia Examiner Dr. Anjali Agarwal Examiner Dr. Amr Youssef Supervisor Dr. J. William Atwood Approved by Dr. Chadi Assi, Graduate Program Director Department of Concordia Institute for Information Systems Engineering 2019 Dr. Amir Asif, Dean Faculty of Engineering and Computer Science Abstract Secure Configuration and Management of Linux Systems using a Network Service Orchestrator Vijay Satti Manual management of the configuration of network devices and computing devices (hosts) is an error-prone task. Centralized automation of these tasks can lower the costs of management, but can also introduce unknown or unanticipated security risks. Miscon- figuration (deliberate (by outsiders) or inadvertent (by insiders)) can expose a system to significant risks. Centralized network management has seen significant progress in recent years, result- ing in model-driven approaches that are clearly superior to previous "craft" methods. Host management has seen less development.
    [Show full text]
  • Plaintext-Recovery Attacks Against Datagram TLS
    Plaintext-Recovery Attacks Against Datagram TLS Nadhem J. AlFardan and Kenneth G. Paterson∗ Information Security Group Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK nadhem.alfardan.2009, kenny.paterson @rhul.ac.uk { } Abstract GnuTLS2. Both of these provide source toolkits that imple- ment TLS and DTLS as well as being general purpose cryp- The Datagram Transport Layer Security (DTLS) proto- tographic libraries that software developers can use. The col provides confidentiality and integrity of data exchanged first release of OpenSSL to implement DTLS was 0.9.8. between a client and a server. We describe an efficient and Since its release, DTLS has become a mainstream proto- full plaintext recovery attack against the OpenSSL imple- col in OpenSSL. There are also a number of commercial mentation of DTLS, and a partial plaintext recovery attack products that have taken advantage of DTLS. For example, against the GnuTLS implementation of DTLS. The attack DTLS is used to secure Virtual Private Networks (VPNs)3,4 against the OpenSSL implementation is a variant of Vaude- and wireless traffic5. Platforms such as Microsoft Windows, nay’s padding oracle attack and exploits small timing differ- Microsoft .NET and Linux can also make use of DTLS6. ences arising during the cryptographic processing of DTLS In addition, the number of RFC documents that are be- packets. It would have been prevented if the OpenSSL im- ing published on DTLS is increasing. Recent examples in- plementation had been in accordance with the DTLS RFC. clude RFC 5415 [1], RFC 5953 [8] and RFC 6012 [13]. A In contrast, the GnuTLS implementation does follow the new version of DTLS is currently under development in the DTLS RFC closely, but is still vulnerable to attack.
    [Show full text]
  • Download CVS 1.11.1P1-3 From: Ftp://Ftp.Software.Ibm.Com/Aix/Freesoftware/Aixtoolbox/RPMS/Ppc/Cvs/ Cvs-1.11.1P1-3.Aix4.3.Ppc.Rpm
    2003 CERT Advisories CERT Division [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. http://www.sei.cmu.edu REV-03.18.2016.0 Copyright 2017 Carnegie Mellon University. All Rights Reserved. This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The view, opinions, and/or findings contained in this material are those of the author(s) and should not be con- strued as an official Government position, policy, or decision, unless designated by other documentation. References herein to any specific commercial product, process, or service by trade name, trade mark, manu- facturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute. This report was prepared for the SEI Administrative Agent AFLCMC/AZS 5 Eglin Street Hanscom AFB, MA 01731-2100 NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribu- tion. Please see Copyright notice for non-US Government use and distribution.
    [Show full text]