DOCSLIB.ORG

Whitepaper - PKCS #11

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Whitepaper - PKCS #11 Whitepaper - PKCS #11 The Role of PKCS #11 in Hardware Security Module Integration The process of incorporating cryptographic technology into an IT security ecosystem typically requires technical integration to add support for vendor Application Programming Interfaces. For many organizations, the flexibility offered by a custom interface is desirable. For others, PKCS #11 provides a standards-based cryptographic library that eliminates the need for extensive integration work. This whitepaper discusses what PKCS #11 is and why it increases the efficiency and ease of incorporating cryptographic hardware into systems of many types and sizes. Defining PKCS #11 Many enterprise-level organizations develop in-house host applications for their core cryptographic infrastructures. To foster communication between hardware security modules and these host applications, the HSM typically provides a proprietary Application Programming Interface (API). APIs can be drastically different between vendors, only sharing the same concepts and cryptographic algorithms, which can lead to an increase in cost and time for integration work. Because of this, there became a need for a standards-based cryptographic library. That’s where PKCS #11 comes in. PKCS #11 (Public-Key Cryptographic Standard #11) is a standard originally developed by RSA Functionality Laboratories and currently maintained by PKCS #11’s design is centered around tokens. In this OASIS. PKCS #11 specifies a standardized API in context, tokens refer to individual devices that are the C programming language that allows easy able to perform cryptographic functions and store automation of cryptographic operations such as either certificates, keys, or data, which are considered encryption, decryption, signing, and verifying. objects. PKCS #11 references cryptographic objects An HSM vendor that supports PKCS #11 provides by creating a logical map of their attributes, such as a software library that bridges the PKCS #11 whether a key is private or public.1 API defined in the standard with their own The attributes assigned to a token object must proprietary API to perform the cryptographic be securely stored inside an HSM or encrypted operations in hardware. Implementations key block to avoid tampering. Within the HSM, of the PKCS #11 API exist that perform the organizations can increase security further by cryptographic operations in software on the host dynamically restricting functionality and limiting computer, but these are less secure because the certain operations or objects to require dual control host application’s hardware can be compromised, for access. leading to the exposure of the encryption keys. PKCS #11 provides key management functionality PKCS #11 is a common choice for software such as key generation, derivation, importing, and vendors who utilize encryption in their cryptogram exporting. All of the most common applications. By allowing the use of a PKCS #11 cryptographic ciphers are supported by the library, module in their application, a software vendor including Triple DES, AES, and RSA. can allow any supported HSM to be a drop-in replacement for software-based encryption. 1: “PKCS #11 Base Functionality v2.30: Cryptoki - Draft 4.” RSA Laboratories, July 2009. FUTUREX.COM The Role of PKCS #11 in Hardware Security Module Integration Integrating with Futurex HSMs Futurex implements a form of the PKCS #11 standard to permit communication between Futurex products and a wide range of applications. With just a few exceptions which have been incorporated to enhance overall security, Futurex supports all functions supplied in PKCS #11, with the addition of some custom functions developed by Futurex in order to increase utility. Futurex HSMs have been tested for PKCS #11 compatibility and certified with numerous common applications. The advantage of using PKCS #11 to foster communication between host applications and hardware security modules lies in how simple it is to perform integration work. If a host application uses software that already supports PKCS #11, it can use the Futurex PKCS #11 module without implementing vendor-specific code. Enabling PKCS #11 on a Futurex Device For organizations operating Futurex devices without PKCS #11 already enabled, the process of adding support is a simple and straightforward one. PKCS #11 is available through Futurex’s General Purpose Cryptography license, which can be implemented through a quick and simple process. 1. Contact the Futurex Xceptional Support Team to request the General Purpose Cryptography license. 2. Access the Futurex device and download a feature update request. 3. Securely transfer the file to the Futurex Xceptional Support Team. 4. After receiving the updated feature update file from the Futurex Xceptional Support team, upload the file into the hardware security module. The Xceptional Support Team will also provide configuration files to use in the host application that will interface with the Futurex hardware security module. 5. After completing the activation process, PKCS #11 functionality will be available for use. Additional Security: Key Labels, Usages, and Security Flags PKCS #11 allows keys to be defined with specific restrictions, such as login requirements and usage restrictions. Through PKCS #11’s logical mapping, defining keys with specific parameters aids in security by limiting the actions that can be performed with them, allowing organizations to strictly control how keys are used. Futurex HSMs have the ability to set these restrictions on key usage and configuration. Below illustrates how these restrictions affect keys that are stored on the HSM or encrypted under a major key: Key Storage Slot Major Key Cryptogram Normal User Admin User Only admin users Only admin users can Can change can use, overwrite, or use or change the No permissions. not private to Private change the key in the Private cryptogram. sensitive. slot. The key in the slot Can change Can change cannot be extracted Unavailable. between not Sensitive not sensitive to from the HSM. Sensitive sensitive and sensitive. The key usage, security sensitive. The key usage and usage, or label cannot Can change security usage cannot Can change not be changed for the between not Immutable be changed for the immutable to key in this slot. The slot Immutable immutable and cryptogram. immutable. cannot be overwritten. immutable. Global Headquarters 864 Old Boerne Road, Bulverde, Texas 78163 USA TF 800.251.5112 P +1 830.980.9782 F +1 830.438.8782 [email protected] WWW.FUTUREX.COM.
Load more

Recommended publications
  • Solution Briefs A10 and Ncipher Strengthen the Security Of
    SOLUTION BRIEF A10 AND nCIPHER STRENGTHEN THE SECURITY OF APPLICATION DELIVERY PLATFORMS A10 THUNDER INTEGRATES WITH nCIPHER nSHIELD TO DELIVER FIPS 140-2 LEVEL 3 PROTECTION OF TLS/SSL KEYS Organizations increasingly depend on application networking CHALLENGE solutions to run critical business processes that involve Protecting and managing the private and sensitive information. To fulfill demands of increasing numbers of TLS/SSL keys—without impacting application businesses, data centers, networks and applications must delivery, performance or compliance not only be available 24-7 and run at optimum speeds, but requirements—is critically important in today’s business environment. must also protect against attacks that could compromise the confidentiality and integrity of the data they process. SOLUTION A10 Thunder ADC integrates with With the reliance on web application services, sensitive nCipher nShield hardware security modules (HSMs) to protect and information exchanged online and in the cloud is at risk manage the TLS/SSL keys. As part of interception and exploitation. Transport layer security/ of this integration, keys are stored in the hardware of nShield HSMs, and secure sockets layer (TLS/SSL) is used to protect sensitive encryption- and signature-processing information by encrypting the data. However, a compromise (involving private keys) are executed within its protected boundary. This of the encryption keys can lead to a breach of the data flowing provides robust protection and between end-user devices and Web servers. With growing management of the cryptographic keys and encryption process. use of TLS/SSL, protecting and managing the underpinning cryptographic keys is a vital function. BENEFITS • Delivers secure application availability and acceleration THE CHALLENGE • Strengthens TLS/SSL cryptographic As organizations and businesses increasingly deliver services key management through Web and cloud-based applications, more sensitive data • Enables robust FIPS 140-2 Level is transacted over TLS/SSL tunnels to protect confidentiality.
    [Show full text]
  • Hardware Security Module for E-Payments
    Hardware Security Module for e-Payments Payment Security in FIPS 140-2 Level 3 Hardware Today's payments industry has increasingly become a target for fraud. To address rising levels of disputed transactions, the card associations have introduced advanced security controls, including improved authentication techniques that demand sophisticated hardware-based cryptographic processing. The nCipher hardware security module (HSM) INDUSTRY APPLICATION payShield option is designed to meet the stringent security requirements of the payments The payShield Option Pack for nCipher HSM industry, strengthening the security of card and provides payments functionality to secure and PIN authentication systems by securing accelerate payments industry applications. transaction processes in a FIPS 140-2 Level 3* ePayments validated tamper-resistant environment. In The 3-D Secure specification mandates the use addition to providing increased security, of FIPS certified hardware for storage and PRODUCT SHEET DATA payShield enabled HSM can dramatically management of cryptographic keys. payShield increase transaction throughput by processing provides a single HSM solution that supports high volumes of symmetric and asymmetric Visa's 3-D Secure Cardholder Authentication cryptographic operations, an important Verification Value (CAVV) using the Visa Card requirement of payments initiatives such as Verification Value (CVV) method, as well as 3-D Secure, Visa DPA, MasterCard CAP. MasterCard’s SPA Account Authentication Value *Federal Information Processing Standard (FIPS) 140-2 Level 3 is (AAV) and Card Authentication Program (CAP). the international security standard for cryptographic modules EMV smart card support CARDHOLDER EMV is a smart card standard developed by AUTHENTICATION Europay, MasterCard and Visa to address the universal aspects of chip card issuance and Supported by the major card associations, acceptance.
    [Show full text]
  • A Hardware Security Module Is Found Not Immune to Hacking
    Memo 12/06/2019 - TLP:WHITE A Hardware Security Module is found not immune to hacking Reference: Memo [190612-1] Date: 12/06/2019 - Version: 1.1 Keywords: HSM, cryptography, PKCS#11, digital services Sources: publicly available information Key Points Security researchers released a paper revealing how they managed to hack a Hardware Security Module (HSM). HSM-s are used to generate, manipulate and store sensitive cryptographic secrets (SIM cards, credit cards, secure boot hardware, disk and database encryption, PKI...). HSM-s are also used by cloud service providers, such as Google or Amazon, allowing clients to centrally create, manage and use their cryptographic secrets. Summary Researchers from a French technology company, specialising in blockchain and cryptocurrency ecosystems, published and presented a paper detailing how they managed to dump the whole content of a Hardware Security Module (HSM), manufactured by an undisclosed company. In order to achieve this, they proceeded as follows: 1. They started by using legitimate software development kit (SDK) access to their test HSM to upload a firmware module that would give them a shell inside the HSM. Note: A SDK is typically a set of software development tools that allows for the creation of applications for a certain software package, software framework, hardware platform, or computer system. Note that this SDK access was used to discover the vulnerabilities, but is not necessary to exploit them. 2. They then used the shell to run a fuzzer on the internal implementation of PKCS#11 commands to find reliable, exploitable buffer overflows. Note: PKCS#11 refers to public-key cryptography standards or to a programming interface used to create and manipulate cryptographic tokens.
    [Show full text]
  • Key Derivation Functions and Their GPU Implementation
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Key derivation functions and their GPU implementation BACHELOR’S THESIS Ondrej Mosnáˇcek Brno, Spring 2015 This work is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-nc-sa/4.0/ cbna ii Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Ondrej Mosnáˇcek Advisor: Ing. Milan Brož iii Acknowledgement I would like to thank my supervisor for his guidance and support, and also for his extensive contributions to the Cryptsetup open- source project. Next, I would like to thank my family for their support and pa- tience and also to my friends who were falling behind schedule just like me and thus helped me not to panic. Last but not least, access to computing and storage facilities owned by parties and projects contributing to the National Grid In- frastructure MetaCentrum, provided under the programme “Projects of Large Infrastructure for Research, Development, and Innovations” (LM2010005), is also greatly appreciated. v Abstract Key derivation functions are a key element of many cryptographic applications. Password-based key derivation functions are designed specifically to derive cryptographic keys from low-entropy sources (such as passwords or passphrases) and to counter brute-force and dictionary attacks. However, the most widely adopted standard for password-based key derivation, PBKDF2, as implemented in most applications, is highly susceptible to attacks using Graphics Process- ing Units (GPUs).
    [Show full text]
  • Public Key Cryptography Public Key Cryptography
    Public Key Cryptography Public Key Cryptography • Symmetric Key: – Same key used for encryption and decrypiton – Same key used for message integrity and validation • Public-Key Cryptography – Use one key to encrypt or sign messages – Use another key to decrypt or validate messages • Keys – Public key known to the world and used to send you a message – Only your private key can decrypt the message Public Key Private Key Plaintext Ciphertext Plaintext Encryption Decryption ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Public Key Cryptography • Motivations – In symmetric key cryptography, a key was needed between every pair of users wishing to securely communicate • O(n2) keys – Problem of establishing a key with remote person with whom you wish to communicate • Advantages to Public Key Cryptography – Key distribution much easier: everyone can known your public key as long as your private key remains secret – Fewer keys needed • O(n) keys • Disadvantages – Slow, often up to 1000x slower than symmetric-key cryptography ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Cryptography and Complexity • Three classes of complexity: – P: solvable in polynomial time, O(nc) – NP: nondeterministic solutions in polynomial time, deterministic solutions in exponential time – EXP: exponential solutions, O(cn) • Cryptographic problems should be: increasing P – Encryption should be P difficult – Decryption should be P with key NP – Decryption should be NP for attacker EXP • Need problems where complexity of solution depends on knowledge of a key ENTS
    [Show full text]
  • The Double Ratchet Algorithm
    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
    [Show full text]
  • Key Management Guide CIO IT Security
    IT Security Procedural Guide: Key Management CIO-IT Security-09-43 Revision 4 April 13, 2020 Office of the Chief Information Security Officer CIO-IT Security-09-43, Revision 4 Key Management VERSION HISTORY/CHANGE RECORD Person Page Change Posting Change Reason for Change Number of Number Change Change Revision 1 – November 19, 2008 1 Eric Additional References to x.509 Response to comments 1,6,16 Hummel Common Framework Revision 2 – February 25, 2016 1 Salamon Updated Policy and NIST references Updated to current versions of Throughout CIO 2100.1, NIST SP 800-53, and NIST SP 800-57 2 Wilson, Updated GSA Logo, formatting, Updated GSA Logo, formatting Throughout Klemens style changes and style. Revision 3 – March 6, 2018 1 Salamon Removed NIST SP 800-21 and NIST SP 800-21 withdrawn, 2, 7, 17 updated Policy references updated to current CIO 2100.1 2 Salamon Updated Procedural Guide links Updated Procedural Guides 8 3 Dean Changes throughout the document Updated to current guide Throughout to correspond with current guide structure, style, and formatting structure and formatting. Revision 4 – April 13, 2020 1 Richards Updated references and minor Scheduled update Throughout language clarifications 2 Salamon Updated Section 2 to include Operational feedback 7 specific requirements for key management 3 Salamon Scope updated in Section 1.2 Operational feedback 3 U.S. General Services Administration CIO-IT Security-09-43, Revision 4 Key Management Approval IT Security Procedural Guide: Key Management, CIO-IT Security-09-43, Revision 4 is hereby approved for distribution. X Bo Berlas Chief Information Security Officer Contact: GSA Office of the Chief Information Security Officer (OCISO), Security Engineering Division (ISE) at [email protected] U.S.
    [Show full text]
  • On the Security of the PKCS#1 V1.5 Signature Scheme
    On the Security of the PKCS#1 v1.5 Signature Scheme Tibor Jager1 Saqib A. Kakvi1 Alexander May2 September 10, 2018 1Department of Computer Science, Universitat¨ Paderborn ftibor.jager,[email protected] 2Hortz Gortz¨ Institute, Ruhr Universitat¨ Bochum [email protected] Abstract The RSA PKCS#1 v1.5 signature algorithm is the most widely used digital signature scheme in practice. Its two main strengths are its extreme simplicity, which makes it very easy to implement, and that verification of signatures is significantly faster than for DSA or ECDSA. Despite the huge practical importance of RSA PKCS#1 v1.5 signatures, providing formal evidence for their security based on plausible cryptographic hardness assumptions has turned out to be very difficult. Therefore the most recent version of PKCS#1 (RFC 8017) even recommends a replacement the more complex and less efficient scheme RSA-PSS, as it is provably secure and therefore considered more robust. The main obstacle is that RSA PKCS#1 v1.5 signatures use a deterministic padding scheme, which makes standard proof techniques not applicable. We introduce a new technique that enables the first security proof for RSA-PKCS#1 v1.5 signatures. We prove full existential unforgeability against adaptive chosen-message attacks (EUF-CMA) under the standard RSA assumption. Furthermore, we give a tight proof under the Phi-Hiding assumption. These proofs are in the random oracle model and the parameters deviate slightly from the standard use, because we require a larger output length of the hash function. However, we also show how RSA-PKCS#1 v1.5 signatures can be instantiated in practice such that our security proofs apply.
    [Show full text]
  • PKCS #15— a Cryptographic-Token Information Format Standard
    THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the USENIX Workshop on Smartcard Technology Chicago, Illinois, USA, May 10–11, 1999 PKCS #15— A Cryptographic-Token Information Format Standard Magnus Nyström RSA Laboratories © 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org PKCS #15 – A Cryptographic Token Information Format Standard Magnus Nyström RSA Laboratories, Bedford MA 01730, USA E-mail: [email protected] acceptance and use of them both by application Abstract developers and by consumers will be muted. We identify the need for a portable format for storage of To optimize the benefit to both the industry and end- user credentials (certificates, keys) on cryptographic users, it is important that solutions to these issues be tokens such as integrated circuit cards (IC cards). Given developed in a manner that supports a variety of this need, a recent proposal in the area, RSA operating environments, application programming Laboratories' PKCS #15 is described and compared with interfaces, and a broad base of applications. Only previous and related work. through this approach can the needs of constituencies be supported and the development of credentials-activated applications encouraged, as a cost-effective solution to 1 Background and Motivation meeting requirements in a very diverse set of markets.
    [Show full text]
  • HSM SECURITY Securing PKCS#11 Interfaces
    HSM SECURITY Securing PKCS#11 Interfaces Whitepaper v1.9 August 2019 Cryptosense | HSM Security Whitepaper 2 Contents 1. Introduction 3 2. Brief History of PKCS#11 3 3. Overview of PKCS#11 Design 3 4. Threat Scenario and Security Properties for PKCS#11 4 5. Attacking PKCS#11 HSM Security 5 5.1. Memory corruption attacks 5 5.2. Non-compliant PKCS#11 Implementations 6 5.3. Errors in Crypto Implementation 7 5.4. Attacks on Compliant PKCS#11 Implementations 7 6. Errors in Using the HSM 9 6.1. Insecure Crypto Mechanisms 10 6.2. Misuse of Crypto 10 6.3. Key Management Failures 10 7. Summary 10 8. About Cryptosense 11 9. Bibliography 11 This document is protected by copyright. No part of the document may be reproduced or redistributed in any form by any means without the prior written authorization of Cryptosense. This document is provided “as is" without any warranty of any kind. Cryptosense SA cannot be held responsible for any misconduct or malicious use of this document by a third party or damage caused by any information this document contains. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Cryptosense SA, 231 Rue Saint-Honoré, 75001 Paris France cryptosense.com © Cryptosense 2019 Cryptosense | HSM Security Whitepaper 3 1. Introduction Modern applications that use cryptography usually access that functionality via an application program interface (API) to a software or hardware cryptographic provider. Security-critical applications often make use of Hardware Security Modules (HSMs): special purpose computers that provide high-speed cryptographic services whilst keeping key material inside a tamper- sensitive enclosure.
    [Show full text]
  • Introduction to Public Key Infrastructures
    Introduction to Public Key Infrastructures Johannes A. Buchmann • Evangelos Karatsiolis Alexander Wiesmaier Introduction to Public Key Infrastructures 123 Johannes A. Buchmann Evangelos Karatsiolis FB Informatik FlexSecure GmbH TU Darmstadt Darmstadt Darmstadt Germany Germany Alexander Wiesmaier AGT International Darmstadt Germany ISBN 978-3-642-40656-0 ISBN 978-3-642-40657-7 (eBook) DOI 10.1007/978-3-642-40657-7 Springer Heidelberg New York Dordrecht London Library of Congress Control Number: 2013954524 © Springer-Verlag Berlin Heidelberg 2013 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
    [Show full text]
  • Spoofing a Hardware Security Module
    DEVELOPING AND CONNECTING ISSA CYBERSECURITY LEADERS GLOBALLY Spoofing a Hardware Security Module By Jeff Stapleton – ISSA member, St. Louis Chapter This article compares valid key management techniques using a cryptographic hardware security module (HSM) with commonly used untrustworthy software-based crypto methods that basically spoof the HSM. Two hardware-based techniques are contrasted with three hybrid-based methods. Security issues for the software-based methods are discussed, and an alternative standards- based scheme is introduced. Abstract This article compares valid key management tech- niques using a cryptographic hardware security module (HSM) with commonly used untrustworthy software-based crypto methods that basically spoof the HSM. Software-based cryptography is generally Figure 1 – Hardware cheaper and easier to implement but at higher risk data encryption of key compromise whereas hardware-based cryp- tography has vastly lower risks but at greater costs and com- key encryption. The HSM spoofing problem arises when the plexity. Attempts at combining software-based crypto with data encryption is performed in software but the key man- hardware-based key management often introduces poor key agement is attempted in cryptographic hardware. Three un- management solutions. Two hardware-based techniques are trustworthy key management methods are contrasted with contrasted with three hybrid-based methods. Security issues the valid techniques: faux key, KMIP unwrapped keys, and for the software-based methods are discussed, and an alter- PKCS#12 password based key derivation functions [2]. The se- native standards-based scheme is introduced. curity weaknesses are explained and an alternate method is in- troduced: database encryption key management (DBEKM) [3]. his article compares valid key management tech- Hardware data encryption niques using a cryptographic hardware security mod- ule (HSM) [1] with commonly used untrustworthy The first HSM key management method discussed is cryp- Tmethods that essentially spoof an HSM.
    [Show full text]