DOCSLIB.ORG

Encryption and Key Management August 26, 2015

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Encryption and Key Management August 26, 2015 Storage Networking Industry Association Technical White Paper Storage Security: Encryption and Key Management August 26, 2015 Abstract: The ISO/IEC 27040:2015 (Information technology - Security techniques - Storage security) standard provides detailed technical guidance on controls and methods for securing storage systems and ecosystems. This whitepaper describes the recommended guidelines for data confidentiality, including data in motion encryption, data at rest encryption, and key management. The practical implications of these recommendations are discussed from both an end user and storage vendor perspective. USAGE The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that: 1. Any text, diagram, chart, table or definition reproduced shall be reproduced in its entirety with no alteration, and, 2. Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced shall acknowledge the SNIA copyright on that material, and shall credit the SNIA for granting permission for its reuse. Other than as explicitly provided above, you may not make any commercial use of this document, sell any or this entire document, or distribute this document to third parties. All rights not explicitly granted are expressly reserved to SNIA. Permission to use this document for purposes other than those enumerated above may be requested by e-mailing [email protected]. Please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use. All code fragments, scripts, data tables, and sample code in this SNIA document are made available under the following license: BSD 3-Clause Software License Copyright (c) 2014, The Storage Networking Industry Association. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * 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. * Neither the name of The Storage Networking Industry Association (SNIA) nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Encryption and Key Management SNIA Technical White Paper 2 August 26, 2015 DISCLAIMER The information contained in this publication is subject to change without notice. The SNIA makes no warranty of any kind with regard to this specification, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The SNIA shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this specification. Suggestions for revisions should be directed to http://www.snia.org/feedback/. Copyright © 2015 SNIA. All rights reserved. All other trademarks or registered trademarks are the property of their respective owners. Encryption and Key Management SNIA Technical White Paper 3 August 26, 2015 Revision History Revision Date Sections Originator: Comments All Walt Hubis Initial Draft V0.1 8/25/2014 All Walt Hubis Review Draft V0.2 3/6/2014 All Walt Hubis 1st Ballot Draft V0.3 5/5/2015 All Walt Hubis 2nd Ballot Draft V0.5 7/10/2015 All Eric Hibbard Post-Ballot Draft V07 8/15/2015 All Eric Hibbard 3rd Ballot Draft V08 8/18/2015 All Eric Hibbard Final V09 8/26/2015 Suggestion for changes or modifications to this document should be submitted at http://www.snia.org/feedback/. Foreword This is one of a series of whitepapers prepared by the SNIA Security Technical Working Group to provide an introduction and overview of important topics in ISO/IEC 27040:2015, Information technology – Security techniques – Storage security. While not intended to replace the standard, they provide additional explanations and guidance beyond that found in the actual standard. Encryption and Key Management SNIA Technical White Paper 4 August 26, 2015 Executive Summary Increasingly, cryptographic mechanisms such as encryption and key management are being used in storage ecosystems to protect data transferred to (data in motion) and stored (data at rest) in data storage systems. To effectively use these technologies, organizations need to understand the benefits, issues, implications, and the limitations, especially when sensitive and high-value data are involved. This storage security whitepaper leverages the guidance in the ISO/IEC 27040 standard and provides value added information on encryption and key management as it relates to storage systems and ecosystems. 1 Introduction The application of encryption to a storage ecosystem can afford very different protections depending on how and where it is integrated. For example, encrypting files or shares within a Network Attached Storage (NAS) file system can offer user-specific protections that are not possible with encryption at the drive level. Thus, it is important to understand the reasons encryption should be considered (that is, which threats are to be mitigated). ISO/IEC 27040:2015 Information technology - Security techniques - Storage security provides detailed technical guidance on controls and methods for securing storage systems and ecosystems (see Appendix A for an overview). While the coverage of this standard is quite broad it does lack specific guidance for certain topics that could enhance the protections. This is partially true with regard to encryption and key management. This whitepaper, which is one in a series from SNIA that addresses various elements of storage security, is intended to leverage the guidance in the ISO/IEC 27040 standard and build upon it with a specific focus on encryption and key management. In addition, it incorporates industry insights with certain security features and capabilities. The whitepaper provides background information on encryption and key management, summarizes the security options, explores the relevant ISO/IEC 27040 guidance, and offers addition information that can help in securing storage. 1.1 Confidentiality and Secrecy Confidentiality is the property whereby information is available to authorized parties on demand but never available to unauthorized parties. Secrecy is a term that is often used synonymously with confidentiality. Cryptographic mechanisms are one of the strongest ways to provide confidentiality and other security services in applications and protocols for data storage. 1 Confidentiality is often achieved using encryption to render the information unintelligible to unauthorized entities. The information is rendered intelligible to authorized entities by 1 A general introduction to cryptography is Cryptography Decrypted by H. X. Mel and Doris Baker (Addison- Wesley:2000 ISBN 978-0201616477) Encryption and Key Management SNIA Technical White Paper 5 August 26, 2015 decryption. In order for encryption to provide confidentiality, the cryptographic algorithm and mode of operation must be designed and implemented so that an unauthorized party cannot determine the secret or private keys2 associated with the encryption or be able to derive the plaintext directly without determining any keys. 1.2 Encryption Overview The primary purpose of encryption (or encipherment) systems is to protect the confidentiality of stored or transmitted data. Encryption algorithms achieve this by transforming plaintext into ciphertext, from which it is computationally infeasible to find any information about the content of the plaintext unless the decryption key is also known. However, the length of the plaintext will generally not be concealed by encryption, since the length of the ciphertext will typically be the same as, or a little larger than, the length of the corresponding plaintext. It is important to note that encryption may not always, by itself, protect the integrity or the origin of data. In many cases it is possible, without knowledge of the key, to modify encrypted text with predictable effects on the recovered plaintext. In order to ensure integrity and origin of data it is often necessary to use additional techniques. There are three basic classes of cryptographic algorithms: hash algorithms, symmetric key algorithms and asymmetric key algorithms. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm. 1.3 Key
Load more

Recommended publications
  • Advanced Encryption Standard Real-World Alternatives
    Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives CPSC 367: Cryptography and Security Michael Fischer Lecture 7 February 5, 2019 Thanks to Ewa Syta for the slides on AES CPSC 367, Lecture 7 1/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Multiple Encryption Composition Group property Birthday Attack Advanced Encryption Standard AES Real-World Issues Alternative Private Key Block Ciphers CPSC 367, Lecture 7 2/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Multiple Encryption CPSC 367, Lecture 7 3/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Composition of cryptosystems Encrypting a message multiple times with the same or different ciphers and keys seems to make the cipher stronger, but that's not always the case. The security of the composition can be difficult to analyze. For example, with the one-time pad, the encryption and decryption functions Ek and Dk are the same. The composition Ek ◦ Ek is the identity function! CPSC 367, Lecture 7 4/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Composition within practical cryptosystems Practical symmetric cryptosystems such as DES and AES are built as a composition of simpler systems. Each component offers little security by itself, but when composed, the layers obscure the message to the point that it is difficult for an adversary to recover. The trick is to find ciphers that successfully hide useful information from a would-be attacker when used in concert. CPSC 367, Lecture 7 5/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Double Encryption Double encryption is when a cryptosystem is composed with itself.
    [Show full text]
  • The Data Encryption Standard (DES) – History
    Chair for Network Architectures and Services Department of Informatics TU München – Prof. Carle Network Security Chapter 2 Basics 2.1 Symmetric Cryptography • Overview of Cryptographic Algorithms • Attacking Cryptographic Algorithms • Historical Approaches • Foundations of Modern Cryptography • Modes of Encryption • Data Encryption Standard (DES) • Advanced Encryption Standard (AES) Cryptographic algorithms: outline Cryptographic Algorithms Symmetric Asymmetric Cryptographic Overview En- / Decryption En- / Decryption Hash Functions Modes of Cryptanalysis Background MDC’s / MACs Operation Properties DES RSA MD-5 AES Diffie-Hellman SHA-1 RC4 ElGamal CBC-MAC Network Security, WS 2010/11, Chapter 2.1 2 Basic Terms: Plaintext and Ciphertext Plaintext P The original readable content of a message (or data). P_netsec = „This is network security“ Ciphertext C The encrypted version of the plaintext. C_netsec = „Ff iThtIiDjlyHLPRFxvowf“ encrypt key k1 C P key k2 decrypt In case of symmetric cryptography, k1 = k2. Network Security, WS 2010/11, Chapter 2.1 3 Basic Terms: Block cipher and Stream cipher Block cipher A cipher that encrypts / decrypts inputs of length n to outputs of length n given the corresponding key k. • n is block length Most modern symmetric ciphers are block ciphers, e.g. AES, DES, Twofish, … Stream cipher A symmetric cipher that generats a random bitstream, called key stream, from the symmetric key k. Ciphertext = key stream XOR plaintext Network Security, WS 2010/11, Chapter 2.1 4 Cryptographic algorithms: overview
    [Show full text]
  • Diffie-Hellman (1976) – RSA (1977) – More Recently: ID-Based Encryption (2001), Functional Encryption (2011)…
    Key Management Shared key Alice Bob c = E(k, p) c p E(.) D(.) p = D(e, c) network k k • k: shared secret key (128 bits) A.A. 2012-2013 Key management 2 Pairwise keys • Each pair of users shares an long-term secret key Alice Bob • Properties • Every user stores (n -1) keys • The overall number of keys is O(n2) Carol Eve Dave A.A. 2012-2013 Key management 3 Pairwise keys • Pros – If a subject is compromised only its communications are compromised; • communications between two other subjects are not compromised • We cannot do any better! • Cons – Poor scalability: the number of keys is quadratic in the number of subjects – Poor scalability: a new member’s joining and a member’s leaving affect all current members A.A. 2012-2013 Key management 4 Trusted Third Party • Online Trusted Third Party (TTP) – Each user shares a long-term secret key with TTP TTP – Every user stores one key – The overall number of keys is n KA KB • TTP is a single point of failure – TTP must be always online A B – TTP knows all the keys • TTP can read all msg between Alice and Bob KAB • TTP can impersonate any party A.A. 2012-2013 Key management 5 Key distribution: a toy protocol Alice wants a shared key with Bob. Eavesdropping security only Bob (kB) Alice (kA) TTP “Alice wants key with Bob” choose E(KA, “A, B” || KAB) random kAB ticket ticket ← E(KB, “A, B” || KAB) kAB kAB Subject to replay attacks A.A. 2012-2013 Key management 6 Key distribution: toy protocol • Insecure against replay attacks (active adversary) – Attacker records session between Alice and merchant Bob • For example: an order – Attacker replays session to Bob • Bob thinks Alice is ordering another copy of the book A.A.
    [Show full text]
  • Ansi/Scte 23-2 2017
    ENGINEERING COMMITTEE Data Standards Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 23-2 2017 DOCSIS 1.1 Part 2: Baseline Privacy Plus Interface ANSI/SCTE 23-2 2017 NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards and Operational Practices (hereafter called “documents”) are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability, best practices and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non-member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members. SCTE assumes no obligations or liability whatsoever to any party who may adopt the documents. Such adopting party assumes all risks associated with adoption of these documents, and accepts full responsibility for any damage and/or claims arising from the adoption of such documents. Attention is called to the possibility that implementation of this document may require the use of subject matter covered by patent rights. By publication of this document, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this document have been requested to provide information about those patents and any related licensing terms and conditions.
    [Show full text]
  • AWS Key Management Service Cryptographic Details
    AWS Key Management Service Cryptographic Details August 2016 Amazon Web Services – AWS KMS Cryptographic Details August 2016 © 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved. Notices This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether express or implied. This document does not create any warranties, representations, contractual commitments, conditions or assurances from AWS, its affiliates, suppliers or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. Page 2 of 42 Amazon Web Services – AWS KMS Cryptographic Details August 2016 Contents Abstract 4 Introduction 4 Design Goals 5 Background 7 Cryptographic Primitives 7 Basic Concepts 9 Customer’s Key Hierarchy 11 Use Cases 13 Amazon EBS Volume Encryption 13 Envelope Encryption 14 Customer Master Keys 17 Imported Master Keys 19 Enable and Disable Key 22 Key Deletion 22 Rotate Customer Master Key 23 Customer Data Operations 23 Application-Specific Data Keys 24 Encrypt 26 Decrypt 26 Re-Encrypting an Encrypted Object 28 Internal Communication Security 29 HSA Security Boundary 29 Quorum-Signed Commands 30 Authenticated Sessions 31 Domains and the Domain State 32 Page 3 of 42 Amazon Web Services – AWS KMS Cryptographic Details August 2016 Domain Keys 33 Exported Domain Tokens 33 Managing Domain State 34 Durability Protection 36 References 38 Appendix - Abbreviations and Keys 40 Abbreviations 40 Keys 41 Contributors 42 Document Revisions 42 Abstract AWS Key Management Service (AWS KMS) provides cryptographic keys and operations scaled for the cloud.
    [Show full text]
  • Dell EMC Unity: Data at Rest Encryption a Detailed Review
    Technical White Paper Dell EMC Unity: Data at Rest Encryption A Detailed Review Abstract This white paper explains the Data at Rest Encryption feature, which provides controller-based encryption of data stored on Dell EMC™ Unity storage systems to protect against unauthorized access to lost or stolen drives or system. The encryption technology as well as its implementation on Dell EMC Unity storage systems are discussed. June 2021 H15090.6 Revisions Revisions Date Description May 2016 Initial release – Unity OE 4.0 July 2017 Updated for Unity OE 4.2 June 2021 Template and format updates. Updated for Unity OE 5.1 Acknowledgments Author: Ryan Poulin The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any software described in this publication requires an applicable software license. This document may contain certain words that are not consistent with Dell's current language guidelines. Dell plans to update the document over subsequent future releases to revise these words accordingly. This document may contain language from third party content that is not under Dell's control and is not consistent with Dell's current guidelines for Dell's own content. When such third party content is updated by the relevant third parties, this document will be revised accordingly. Copyright © 2016-2021 Dell Inc. or its subsidiaries. All Rights Reserved. Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc.
    [Show full text]
  • Multiple Results on Multiple Encryption
    Multiple Results on Multiple Encryption Itai Dinur, Orr Dunkelman, Nathan Keller, and Adi Shamir The Security of Multiple Encryption: Given a block cipher with n-bit plaintexts and n-bit keys, we would like to enhance its security via sequential composition Assuming that – the basic block cipher has no weaknesses – the k keys are independently chosen how secure is the resultant composition? P C K1 K2 K3 K4 Double and Triple Encryptions: Double DES and triple DES were widely used by banks, so their security was thoroughly analyzed By using a Meet in the Middle (MITM) attack, Diffie and Hellman showed in 1981 that double encryption can be broken in T=2^n time and S=2^n space. Note that TS=2^{2n} Given the same amount of space S=2^n, we can break triple encryption in time T=2^{2n}, so again TS=2^{3n} How Secure is k-encryption for k>3? The fun really starts at quadruple encryption (k=4), which was not well studied so far, since we can show that breaking 4-encryption is not harder than breaking 3-encryption when we use 2^n space! Our new attacks: – use the smallest possible amount of data (k known plaintext/ciphertext pairs which are required to uniquely define the k keys) – Never err (if there is a solution, it will always be found) The time complexity of our new attacks (expressed by the coefficient c in the time formula T=2^{cn}) k = c = The time complexity of our new attacks (expressed by the coefficient c in the time formula T=2^{cn}) k = 2 c = 1 The time complexity of our new attacks (expressed by the coefficient c in the time
    [Show full text]
  • DOCSIS 3.0 Security Specification
    Data-Over-Cable Service Interface Specifications DOCSIS 3.0 Security Specification CM-SP-SEC3.0-C01-171207 CLOSED Notice This DOCSIS® specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. You may download, copy, distribute, and reference the documents herein only for the purpose of developing products or services in accordance with such documents, and educational use. Except as granted by CableLabs® in a separate written license agreement, no license is granted to modify the documents herein (except via the Engineering Change process), or to use, copy, modify or distribute the documents for any other purpose. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. To the extent this document contains or refers to documents of third parties, you agree to abide by the terms of any licenses associated with such third-party documents, including open source licenses, if any. Cable Television Laboratories, Inc., 2006-2017 CM-SP-SEC3.0-C01-171207 Data-Over-Cable Service Interface Specifications DISCLAIMER This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein.
    [Show full text]
  • A Framework for Designing Cryptographic Key Management Systems
    NIST Special Publication 800-130 A Framework for Designing Cryptographic Key Management Systems Elaine Barker Miles Smid Dennis Branstad Santosh Chokhani C O M P U T E R S E C U R I T Y NIST Special Publication 800-130 A Framework for Designing Cryptographic Key Management Systems Elaine Barker Computer Security Division Information Technology Laboratory Miles Smid Orion Security Solutions Silver, Spring, MD Dennis Branstad NIST Consultant Austin, TX Santosh Chokhani Cygnacom McLean, VA August 2013 U.S. Department of Commerce Penny Pritzker, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director SP 800-130 August 2013 Authority This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Aes Encryption Java Example Code
    Aes Encryption Java Example Code Emerging and gleg Whitby enduing: which Paten is minuscule enough? Emasculate Roderic evaded aversely while Hamel always incinerated his trio decollating ontogenetically, he ferment so scrutinizingly. Sargent is top-level and dialogised esuriently while alchemical Rickey delimitated and claw. How to Encrypt and Decrypt using AES in Java JavaPointers. Typically the first time any longer preclude subsequent encryption attempts. Java AES encryption and decryption with static secret. Strategies to keep IV The IV used to encrypt the message is best to decrypting the message therefore leaving question is raised, the data contained in multiple files should have used several keys to encrypt the herd thus bringing down risk of character total exposure loss. AES Encryption with HMAC Integrity in Java netnixorg. AES was developed by two belgian cryptographers. Gpg key example, aes encryption java service encrypt text file, and is similar to connect to read the codes into different. It person talk about creating AES keys and storing AES keys in a JCEKS keystore format. As a predecessor value initialization vector using os. Where to Go live Here? Cipher to took the data bank it is passed to the underlying stream. This code if you use aes? Change i manage that you how do. Copyright The arc Library Authors. First house get an arms of Cipher for your chosen encryption type. To encrypt the dom has access to java encryption? You would do the encryption java service for file transfer to. The java or? Find being on Facebook and Twitter. There put two ways for generating a digit key is used on each router that use.
    [Show full text]
  • LEVERAGING VENAFI TRUSTFORCE and A10 THUNDER ADC to SIMPLIFY CERTIFICATE MANAGEMENT Automate Management and Security of the Entire Certificate Lifecycle Process
    SOLUTION BRIEF LEVERAGING VENAFI TRUSTFORCE AND A10 THUNDER ADC TO SIMPLIFY CERTIFICATE MANAGEMENT Automate Management and Security of the Entire Certificate Lifecycle Process Applications of all types have migrated to the web and use Secure Sockets Layer (SSL) Challenge: and Transport Layer Security (TLS) encryption to secure user sessions. To authenticate Organizations need to not only manage sites, organizations rely on cryptographic keys and digital certificates to establish trust the lifecycle of all digital certificates but for countless business activities. Such electronic countermeasures safeguard transactions ensure that any vulnerabilities are found and prevent spoofed sites and snooping by malevolent hackers or other cyber criminals. and automatically rectified. The difficulty Users gain confidence in such applications, allowing their use to flourish with an of this undertaking is magnified when exponential increase in productivity. certificates are configured on various network infrastructure elements. However, the very trust that keys and certificates establish has become a source of attack. When organizations instinctively trust keys and certificates, cybercriminals can Solution: turn compromised ones against them. Worse, organizations often have limited visibility A10 Networks Thunder ADC line of into their vulnerabilities and a restricted ability to respond to breaches. Offenders are Application Delivery Controllers is able to successfully steal data while remaining undetected for months, or even years. fully interoperable with Venafi’s Trust These key and certificate weaknesses lead to significant security risks that demand Protection Platform. Together, this joint immediate action. solution enables control over all digital certificates present, while allowing full Organizations must secure their key and certificate portfolio and identify their remediation of any anomalies.
    [Show full text]
  • Key Management
    Key Management Key management refers to the distribution of cryptographic keys; the mechanisms used to bind an identity to a key; and the generation, maintenance, and revoking of such keys. The notation that we will use is X → Y: { Z } k means that entity X sends to entity Y a message Z encrypted with the key k e.g. Alice → Bob: { “Hello World” } k means that Alice send Bob the message “Hello World” using key k. k represents the secret key for the classical (symmetrical) key encryption system. e and d represent the public and private key, respectively, for a public key (asymmetrical) encryption system. Session and Interchange Keys Def: An interchange key is a cryptographic key associated with a principal to a communication. Def: A session key is a cryptographic key associated with the communications itself talk about way to communicate different key for each communications A session key prevents forward searches Forward Search Attack small number of plain text messages encrypt with a public key compare to sent messages know plain text message e.g. Suppose that Alice is a client of Bob’s stock brokerage firm. Alice need to send Bob one of two messages: BUY or SELL. Cathy, the attacker, enciphers both messages with Bob’s public key. When Alice sends her message, Cathy compares it with her enciphered messages and sees which one it matches. Randomly generated session key that are used once prevents this type of attack. An interchange key used to convince receiver who the sender is used for all sessions changes independently of session initiation and termination Key Exchange e.g.
    [Show full text]