Guidelines on Cryptographic Algorithms Usage and Key Management

Total Page:16

File Type:pdf, Size:1020Kb

Guidelines on Cryptographic Algorithms Usage and Key Management Guidelines on cryptographic algorithms usage and key management EPC342-08 / Version 10.0 / Produced by PSSG / Date issued: 8 March 2021 This document defines guidelines on cryptographic algorithms usage and key management. © 2021 Copyright European Payments Council (EPC) AISBL: This document is public and may be copied or otherwise distributed provided attribution is made and the text www.epc-cep.eu is not used directly as a source of profit 1 / 75 Guidelines Cryptographic algorithms usage and key management EPC342-08 2021 version 10.0 Date issued: 8 March 2021 Table of Contents Executive Summary .................................................................................................................... 6 1 Introduction ......................................................................................................................... 8 1.1 Scope of the document .............................................................................................................. 8 1.2 Document structure ................................................................................................................... 8 1.3 Recommendations ..................................................................................................................... 9 1.4 Implementation best practices ................................................................................................ 12 2 Algorithm Taxonomy ......................................................................................................... 14 2.1 Technical Characteristics .......................................................................................................... 14 2.1.1 Primitives........................................................................................................................ 14 2.1.2 Elementary Constructions .............................................................................................. 16 2.2 Typical Usage............................................................................................................................ 17 2.2.1 Confidentiality Protection .............................................................................................. 18 2.2.2 Integrity Protection ........................................................................................................ 19 2.3 Standardisation ........................................................................................................................ 19 3 Algorithm Related Design Issues ........................................................................................ 21 3.1 Primitives.................................................................................................................................. 21 3.1.1 Unkeyed ......................................................................................................................... 21 3.1.2 Symmetric Key ............................................................................................................... 22 3.1.3 Asymmetric key .............................................................................................................. 23 3.1.4 Security levels ................................................................................................................ 28 3.1.5 Quantum computing considerations ............................................................................. 30 3.1.6 ISO Recommendation for Financial Services ................................................................. 33 3.2 Constructions ........................................................................................................................... 33 3.2.1 Symmetric Key Encryption ............................................................................................. 33 3.2.2 Asymmetric Encryption .................................................................................................. 35 www.epc-cep.eu 2 / 75 Guidelines on cryptographic algorithms usage and key management EPC342-08 / 2021 version 10.0 3.2.3 Hybrid Encryption .......................................................................................................... 35 3.2.4 MACs .............................................................................................................................. 36 3.2.5 Digital Signatures ........................................................................................................... 37 3.2.6 Authenticated Encryption .............................................................................................. 38 3.2.7 Distributed ledger technologies ..................................................................................... 39 3.3 Domain of Application ............................................................................................................. 42 3.4 Implementation and interoperability issues ............................................................................ 42 3.4.1 Security protocols .......................................................................................................... 42 3.4.2 Data formatting issues ................................................................................................... 44 3.4.3 Implementation rules..................................................................................................... 44 3.4.4 Key management impact on interoperability ................................................................ 45 3.4.5 Implementation quality and side-channel attacks ........................................................ 45 3.4.6 Algorithm OIDs ............................................................................................................... 46 4 Key Management Issues ..................................................................................................... 47 4.1 Symmetric algorithms .............................................................................................................. 47 4.1.1 Key generation and derivation ....................................................................................... 47 4.1.2 Key backup and storage ................................................................................................. 48 4.1.3 Key distribution .............................................................................................................. 49 4.1.4 Key installation ............................................................................................................... 49 4.1.5 Key usage and key separation ........................................................................................ 50 4.1.6 Key deletion ................................................................................................................... 51 4.1.7 Key cryptoperiod ............................................................................................................ 51 4.2 Asymmetric algorithms ............................................................................................................ 51 4.2.1 Key generation ............................................................................................................... 52 4.2.2 Example of a hybrid key architecture ............................................................................ 52 4.2.3 Key backup and storage ................................................................................................. 53 4.2.4 Key distribution .............................................................................................................. 54 4.2.5 Key agreement and forward secrecy ............................................................................. 55 4.2.6 Public Key installation .................................................................................................... 55 4.2.7 Certificate revocation and expiry ................................................................................... 55 4.2.8 Key usage and key separation ........................................................................................ 56 4.2.9 Key deletion and archiving ............................................................................................. 56 4.2.10 Key crypto period ........................................................................................................ 56 4.3 Key recovery and key escrow ................................................................................................... 57 www.epc-cep.eu 3 / 75 Guidelines on cryptographic algorithms usage and key management EPC342-08 / 2021 version 10.0 5 Random Numbers .............................................................................................................. 58 6 ANNEX I: Terminology ........................................................................................................ 60 7 ANNEX II: Bibliography ....................................................................................................... 64 List of figures Figure 1: A technical taxonomy of cryptographic primitives and mechanisms .......... 14 Figure 2: Example of key hierarchy for symmetric keys ....................................... 48 Figure 3: A hybrid key hierarchy with asymmetric and symmetric keys (for data confidentiality) ............................................................................................. 53 List of tables Table 1: Recommendations ............................................................................. 12 Table 2: Implementation
Recommended publications
  • Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3
    Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3 Phong Q. Nguyen CNRS/Ecole´ normale sup´erieure D´epartement d’informatique 45 rue d’Ulm, 75230 Paris Cedex 05, France. [email protected] http://www.di.ens.fr/˜pnguyen Abstract. More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary soft- ware, one cannot say much unless one proceeds to reverse-engineering, and history tends to show that bad cryptography is much more frequent than good cryptography there. Open source software thus sounds like a good solution, but the fact that a source code can be read does not imply that it is actually read, especially by cryptography experts. In this paper, we illustrate this point by examining the case of a basic In- ternet application of cryptography: secure email. We analyze parts of thesourcecodeofthelatestversionofGNUPrivacyGuard(GnuPGor GPG), a free open source alternative to the famous PGP software, com- pliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We ob- serve several cryptographic flaws in GPG v1.2.3. The most serious flaw has been present in GPG for almost four years: we show that as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer’s private key in less than a second on a PC. As a consequence, ElGamal signatures and the so-called ElGamal sign+encrypt keys have recently been removed from GPG.
    [Show full text]
  • Security Analysis and Trust Models in Wireless Networks Lela Mirtskhulava
    Security Analysis and Trust Models in Wireless Networks Lela Mirtskhulava [email protected] Department of Computer Sciences Faculty of Exact and Natural Sciences Iv. Javakhishvili Tbilisi State University University str., 13, Georgia In the given work, we analyse the serious weaknesses recently discovered in WPA2 (Wi-Fi Protected Access 2) in October 2017 and KRACK (Key Reinstallation Attack) attack on WPA2 announced by Computer Science Scientists. The KRACKs were introduced to abuse design flaws in cryptographic protocols to reinstall an already-in-use key. Several types of cryptographic Wi-Fi handshakes are affected by the attack. There are different forms of trust to address different types of network security problems and reduce risk in certain conditions. This paper explores the trust models applied by various cryptographic schemes: a) the web of trust employed by Pretty Good Privacy (PGP) where users using their own set of trusted public keys, b) Kerberos, a secret key distribution scheme using a trusted third party, c) certificates, which allow a set of trusted third parties to authenticate each other and, by implication, each other's users. Each of the above mentioned trust models differs in complexity, scope, scalability and general applicability. Which model of trust to apply in certain circumstances and types of wireless networks are discussed in the given paper. It describes the major security issues and their techniques of building trust model by monitoring network behavior. It is intended to use secure and faster cryptographic solution for Wi-Fi networks security by using an open source public-key NTRU cryptosystem that uses lattice-based cryptography.
    [Show full text]
  • SIGMA: the 'Sign-And-Mac' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols
    SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols ∗ Hugo Krawczyky June 12, 2003 Abstract We present the SIGMA family of key-exchange protocols and the \SIGn-and-MAc" approach to authenticated Diffie-Hellman underlying its design. The SIGMA protocols provide perfect forward secrecy via a Diffie-Hellman exchange authenticated with digital signatures, and are specifically designed to ensure sound cryptographic key exchange while supporting a variety of features and trade-offs required in practical scenarios (such as optional identity protection and reduced number of protocol rounds). As a consequence, the SIGMA protocols are very well suited for use in actual applications and for standardized key exchange. In particular, SIGMA serves as the cryptographic basis for the signature-based modes of the standardized Internet Key Exchange (IKE) protocol (versions 1 and 2). This paper describes the design rationale behind the SIGMA approach and protocols, and points out to many subtleties surrounding the design of secure key-exchange protocols in general, and identity-protecting protocols in particular. We motivate the design of SIGMA by comparing it to other protocols, most notable the STS protocol and its variants. In particular, it is shown how SIGMA solves some of the security shortcomings found in previous protocols. ∗A shortened version of this paper appears in the proceedings of CRYPTO'03. For further information related to the SIGMA protocols see http://www.ee.technion.ac.il/~hugo/sigma.html yEE Department, Technion, Haifa, Israel, and IBM T.J. Watson Research Center. Email: [email protected] 1 Contents 1 Introduction 1 2 Preliminaries: On the Security of Key-Exchange Protocols 4 2.1 Overview of the security model and requirements .
    [Show full text]
  • Harris Sierra II, Programmable Cryptographic
    TYPE 1 PROGRAMMABLE ENCRYPTION Harris Sierra™ II Programmable Cryptographic ASIC KEY BENEFITS When embedded in radios and other voice and data communications equipment, > Legacy algorithm support the Harris Sierra II Programmable Cryptographic ASIC encrypts classified > Low power consumption information prior to transmission and storage. NSA-certified, it is the foundation > JTRS compliant for the Harris Sierra II family of products—which includes two package options for the ASIC and supporting software. > Compliant with NSA’s Crypto Modernization Program The Sierra II ASIC offers a broad range of functionality, with data rates greater than 300 Mbps, > Compact form factor legacy algorithm support, advanced programmability and low power consumption. Its software programmability provides a low-cost migration path for future upgrades to embedded communications equipment—without the logistics and cost burden normally associated with upgrading hardware. Plus, it’s totally compliant with all Joint Tactical Radio System (JTRS) and Crypto Modernization Program requirements. The Sierra II ASIC’s small size, low power requirements, and high data rates make it an ideal choice for battery-powered applications, including military radios, wireless LANs, remote sensors, guided munitions, UAVs and any other devices that require a low-power, programmable solution for encryption. Specifications for: Harris SIERRA II™ Programmable Cryptographic ASIC GENERAL BATON/MEDLEY SAVILLE/PADSTONE KEESEE/CRAYON/WALBURN Type 1 – Cryptographic GOODSPEED Algorithms* ACCORDION FIREFLY/Enhanced FIREFLY JOSEKI Decrypt High Assurance AES DES, Triple DES Type 3 – Cryptographic AES Algorithms* Digital Signature Standard (DSS) Secure Hash Algorithm (SHA) Type 4 – Cryptographic CITADEL® Algorithms* SARK/PARK (KY-57, KYV-5 and KG-84A/C OTAR) DS-101 and DS-102 Key Fill Key Management SINCGARS Mode 2/3 Fill Benign Key/Benign Fill *Other algorithms can be added later.
    [Show full text]
  • A History of U.S. Communications Security (U)
    A HISTORY OF U.S. COMMUNICATIONS SECURITY (U) THE DAVID G. BOAK LECTURES VOLUME II NATIONAL SECURITY AGENCY FORT GEORGE G. MEADE, MARYLAND 20755 The information contained in this publication will not be disclosed to foreign nationals or their representatives without express approval of the DIRECTOR, NATIONAL SECURITY AGENCY. Approval shall refer specifically to this publication or to specific information contained herein. JULY 1981 CLASSIFIED BY NSA/CSSM 123-2 REVIEW ON 1 JULY 2001 NOT RELEASABLE TO FOREI6N NATIONALS SECRET HA~mLE YIA COMINT CIIA~HJELS O~JLY ORIGINAL (Reverse Blank) ---------- • UNCLASSIFIED • TABLE OF CONTENTS SUBJECT PAGE NO INTRODUCTION _______ - ____ - __ -- ___ -- __ -- ___ -- __ -- ___ -- __ -- __ --- __ - - _ _ _ _ _ _ _ _ _ _ _ _ iii • POSTSCRIPT ON SURPRISE _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I OPSEC--------------------------------------------------------------------------- 3 ORGANIZATIONAL DYNAMICS ___ -------- --- ___ ---- _______________ ---- _ --- _ ----- _ 7 THREAT IN ASCENDANCY _________________________________ - ___ - - _ -- - _ _ _ _ _ _ _ _ _ _ _ _ 9 • LPI _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I I SARK-SOME CAUTIONARY HISTORY __ --- _____________ ---- ________ --- ____ ----- _ _ 13 THE CRYPTO-IGNITION KEY __________ --- __ -- _________ - ---- ___ -- ___ - ____ - __ -- _ _ _ 15 • PCSM _ _ _ _ _ _ _ _ _ _ _ _ _ _
    [Show full text]
  • Security & Privacy for Mobile Phones
    Security & Privacy FOR Mobile Phones Carybé, Lucas Helfstein July 4, 2017 Instituto DE Matemática E Estatística - USP What IS security? • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; 1 • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; 1 • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; 1 Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. 1 Security IS ... A System! Eve | | | Alice "Hi" <---------------> "Hi" Bob 2 Security IS ... Cryptography! Eve | | | Alice "Hi" <----"*****"------> "Hi" Bob 3 Security IS ... Impossible! The ONLY TRULY SECURE SYSTEM IS ONE THAT IS POWERED off, CAST IN A BLOCK OF CONCRETE AND SEALED IN A lead-lined ROOM WITH ARMED GUARDS - AND EVEN THEN I HAVE MY doubts.
    [Show full text]
  • Loki: Location-Based PKI for Social Networks
    LoKI: Location-based PKI for Social Networks Randy Baden University of Maryland [email protected] http://www.cs.umd.edu/~randofu/loki Categories and Subject Descriptors decentralized OSNs. The out-of-band exchange of keys, how- C.2.0 [Computer Communications Networks]: General—Data ever, has proven too onerous for typical users [7]. We therefore communications; C.2.1 [Computer Communications Networks]: choose to design techniques that users are able to more readily Network Architecture and Design—Wireless communication; C.2.4 employ based on how users interact with each other in modern [Computer Communications Networks]: Distributed Systems— settings. Client/server, Distributed applications; C.5.3 [Computer Sys- Our main contribution is a system, LoKI, in which we use the tem Implementation]: Microcomputers—Portable devices (e.g., ubiquity of mobile devices to provide users with a new method laptops, personal digital assistants); E.3 [Data Encryption]: for verifying identities that does not require immediate user in- [Public key cryptosystems] teraction. Concretely, we propose collecting shared secrets from nearby mobile devices over the course of typical mobile activ- ity, then using these shared secrets post-hoc to perform identity General Terms verification based on user recollection of when real-world meet- Security, Design, Performance ings occurred. We estimate the frequency of real-world meet- ings among social network users with a data set of interactions recorded by Foursquare, Facebook, and Twitter. We evaluate Keywords the technical constraints of collecting and storing shared secrets Public Key Infrastructure, Online Social Networks, Location, in terms of storage space and power consumption based on the Mobility frequency of mobile device encounters.
    [Show full text]
  • Analysis of Key Management in Matrix
    Bachelor thesis Computing Science Radboud University Analysis of key management in Matrix Author: First supervisor/assessor: Floris Hendriks Prof. J.J.C. Daemen s4749294 [email protected] Second supervisor: Dr. B.J.M. Mennink [email protected] Second assessor: Dr. C.E. Dobraunig [email protected] January 17, 2020 Abstract This thesis presents an analysis of Matrix’s key management. Matrix is an end-to-end encrypted and decentralised application layer proto- col, developed by The Matrix.org Foundation C.I.C. The protocol is used, among other applications, to end-to-end encrypt messages in a decen- tralised chat system. To date, Matrix is not equipped with a clear and well-described overview on how keys enable end-to-end encryption in a decentralised network. This thesis therefore describes how keys in Ma- trix are established, used, stored, exchanged and verified. Moreover, the analysis also explores the limitations of Matrix’s key management and potential improvements. Contents 1 Introduction3 1.1 Research questions........................5 1.2 Structure..............................6 2 Preliminaries7 2.1 Data formats used in Matrix...................7 2.2 Security principles........................8 2.2.1 Forward secrecy......................8 2.2.2 Backward secrecy.....................8 2.2.3 Deniability.........................8 2.2.4 Confidentiality.......................8 2.2.5 Integrity..........................9 2.2.6 Authentication.......................9 2.3 Cryptographic primitives used in Matrix............9 2.3.1 Cryptographic hash functions..............9 2.3.2 HMAC............................9 2.3.3 HKDF............................ 10 2.3.4 Cryptographic ratchets.................. 10 2.3.5 Curve25519........................ 11 2.3.6 EdDSA and Ed25519..................
    [Show full text]
  • The GNU Privacy Handbook the GNU Privacy Handbook Copyright © 1999 by the Free Software Foundation
    The GNU Privacy Handbook The GNU Privacy Handbook Copyright © 1999 by The Free Software Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front- Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Please direct questions, bug reports, or suggestions concerning this manual to the maintainer, Mike Ashley (<jash- [email protected]>). When referring to the manual please specify which version of the manual you have by using this version string: $Name: v1_1 $. Contributors to this manual include Matthew Copeland, Joergen Grahn, and David A. Wheeler. J Horacio MG has translated the manual to Spanish. Table of Contents 1. Getting Started................................................................................................................................................ 6 Generating a new keypair............................................................................................................................ 6 Generating a revocation certificate .................................................................................................... 8 Exchanging keys ......................................................................................................................................... 8 Exporting a public key......................................................................................................................
    [Show full text]
  • Cryptography and Evidence
    UCAM-CL-TR-780 Technical Report ISSN 1476-2986 Number 780 Computer Laboratory Cryptography and evidence Michael Roe May 2010 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2010 Michael Roe This technical report is based on a dissertation submitted April 1997 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Clare College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Summary The invention of public-key cryptography led to the notion that cryptographically protected mes- sages could be used as evidence to convince an impartial adjudicator that a disputed event had in fact occurred. Information stored in a computer is easily modified, and so records can be falsified or retrospectively modified. Cryptographic protection prevents modification, and it is hoped that this will make cryptographically protected data acceptable as evidence. This usage of cryptogra- phy to render an event undeniable has become known as non-repudiation. This dissertation is an enquiry into the fundamental limitations of this application of cryptography, and the disadvan- tages of the techniques which are currently in use. In the course of this investigation I consider the converse problem, of ensuring that an instance of communication between computer systems leaves behind no unequivocal evidence of its having taken place. Features of communications protocols that were seen as defects from the standpoint of non-repudiation can be seen as benefits from the standpoint of this converse problem, which I call “plausible deniability”.
    [Show full text]
  • User Manual V.1.3 (“NTRU Release”) 1 What Is Goldbug?
    Secure Instant Messenger User Manual v.1.3 (“NTRU Release”) http://goldbug.sf.net 1 What is GoldBug? GoldBug is a secure Instant Messenger. You can be sure with using GoldBug (GB), that no third party can look into your chat communication. Private user-to-user communication remains private. GoldBug therefore uses strong multi-encryption with different layers of modern encryption technologies of well known and revised crypto libraries (like libgcrypt (GnuPG) and OpenSSL). For example it generates more than 8 public / private encryption keys based on RSA or NTRU or ElGamal. The app offers as well decentral and encrypted Email and decentral public E*IRC-Chat. As in every Messenger, you can share and transfer files. With tools like Rosetta Cryptopad and/or the File-Encryption tool you can convert text and files into ciphertext. 2 Why encryption matters: Today mostly every WIFI is protected with a password. In a few years as well every plaintext message or email to friends over the internet will be encrypted too. It is not a question to have something to hide or not, • it is a question to control by yourself the security of your communications - or having it controled by others. • It‘ s a question of free thinking and • taking away the presumption of innocence.*) • Democracy requires the thinking and debate of alternatives in private and public. "The question is not 'do you have something to hide?' Strong-Multi-Encryption ensures the The question is whether we control declaration of human rights in broad constitutional consensi and is a digital or they controls us." - Oliver Stone self-defense, everyone needs to learn http://www.youtube.com/watch?v=0U37hl0n9mY and utilize.
    [Show full text]
  • NSA's Survaliance of the Internet
    NSA’s survaliance of the internet Can open-source help? KLID presentation May 21, 2015 Luke Herbert [email protected] Professionelle Keld Simonsen [email protected] Linux-Interessenter Can open-sourcei Danmark help? May 21, 2015 1/ 82 → Contents 1 Introduction 2 Tailored Access Operations 3 Data Collection 4 Analysis 5 Hacking (Malware) 6 Cryptography 7 Using the Data 8 Open-Source Possibilities 9 Conclusion Can open-source help? May 21, 2015 2/ 82 Introduction → NSA National Security Agency (NSA) ”The National Security Agency/Central Security Service (NSA/CSS) leads the U.S. Government in cryptology that encompasses both Signals Intelligence (SIGINT) and Information Assurance (IA) products and services, and enables Computer Network Operations (CNO) in order to gain a decision advantage for the Nation and our allies under all circumstances.” Can open-source help? May 21, 2015 3/ 82 Introduction → 5 Eyes The 5 Eyes alliance (FVEY) UKUSA Agreement • Great Britain • New Zeeland • Canada • Australia Founded August 1941 Backbone STONEGHOST Intel Network Can open-source help? May 21, 2015 4/ 82 Introduction → Partners Partners as of 2013 Glenn Greenwald: No Place To Hide, May-2014. Can open-source help? May 21, 2015 5/ 82 Introduction → Edward Snowden Edward Snowden • Born: 21 June, 1983 • 2006: CIA System admin. • 2009: Dell Consultant at NSA • One of approx. 1000 NSA admins authorised to access almost all systems. • 2010: NSA allows USB sticks to be used in secure areas. • 2013: Charged with Theft of government property, unauthorized communication of national defense information, and ... Can open-source help? May 21, 2015 6/ 82 Introduction → Publication Edward Snowden (ES) • ES stationed at the NSA’s Remote Operations Center facility in Hawaii.
    [Show full text]