DOCSLIB.ORG

Design and Implementation of Public Key Infrastructure on Smart Card Operating System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Design and Implementation of Public Key Infrastructure on Smart Card Operating System by Aditi Gupta Department of Computer Science and Engineering Indian Institute of Technology Kanpur { 208 016 MAY 2008 Design and Implementation of Public Key Infrastructure on Smart Card Operating System A Thesis Submitted in partial fulfilment of the requirements for the Degree of Master of Technology by Aditi Gupta to the Department of Computer Science and Engineering Indian Institute of Technology Kanpur { 208 016 MAY 2008 Abstract Smart cards are an ideal medium for use in secure applications. Such applications require mechanisms for cryptographic authentication, password based authenti- cation, confidential data exchange, detection of data tampering and verification of origin integrity. Cryptographic techniques based on symmetric key algorithms and/or public key cryptography can be used to address these issues. In this the- sis, we focus on development of public key infrastructure on smart cards. Public key cryptography provides easier key management since keys are assigned on per user basis as opposed to per communication pair basis as in the case of symmetric key cryptography. Further, the public key cryptography can be used to perform key exchange for symmetric key and then the symmetric key cryptography can be used to perform further cryptographic operations. Smart cards are secure devices since the keys are kept in it securely and only the operations using such keys are permitted to be performed. We propose a comprehensive design for development of public key infrastructure on smart cards. This design is compliant to ISO/IEC-7816 international standards for smart cards [2{9] and the SCOSTA-CL specification [1]. We have implemented features like encryption/decryption schemes, storage and retrieval of cryptographic information etc. on the smart card operating system as per our design specifica- tions. ii Acknowledgements I would like to express my gratitude towards my thesis supervisor, Dr. Rajat Moona, for his invaluable guidance and support in completing this thesis work. His enthusiasm, innovative suggestions and deep insight into technical matter were instrumental in the conceptualization of this work. Working under his supervision was a great learning experience. I would also like to thank him for initiating my interest in the areas of operating system and system security. I would like to thank all the people who have been a part of SCOSTA lab for their assistance during various phases of the project. I would like to thank my friends Srishti and Pragya for their patience in reviewing my report and providing valuable feedback. I truly enjoyed working with them. I would like to thank all my friends for always being by my side and making my stay here truly enjoyable and memorable. I'll always cherish the moments I spent with them. I would also like to thank my institute and my department for providing me with the best facilities and a wonderful work environment. I would like to thank all my professors for their words of wisdom and guidance throughout my stay here. Finally, I would like to express my gratitude towards my parents and my brother for their love, support and encouragement in all my endeavours. iii Contents Certificatei Abstract ii Acknowledgements iii List of Figures viii List of Tables ix Abbreviationsx 1 Introduction1 1.1 Motivation................................2 1.2 Related Work..............................4 1.3 Thesis Objective............................5 1.4 Thesis Organization...........................6 2 Background7 2.1 Smart Card Communication Structure................8 2.2 File System............................... 10 2.3 Security Architecture.......................... 11 2.3.1 Security Status......................... 11 2.3.2 Security Attributes....................... 11 2.3.3 Security Environment...................... 12 2.3.4 Security Algorithms....................... 13 2.3.5 Security Mechanisms...................... 14 2.4 Password and Key Repository..................... 15 2.5 Security Mechanisms in SCOSTA-CL.................. 16 2.5.1 Encryption and Decryption.................. 16 2.5.2 Cryptographic Checksum.................... 16 2.5.3 Secure Messaging........................ 17 2.5.4 Session Key Derivation..................... 17 2.5.5 Authentication......................... 17 2.6 Overview of Public Key Cryptography................ 18 iv Contents v 2.6.1 RSA Cryptosystem....................... 19 2.6.2 Primitive Cryptographic Operations.............. 19 2.6.3 Encryption and Decryption Operations............ 20 2.6.4 Digital Signature........................ 21 2.6.5 Certificate Verification..................... 22 3 Design for PKI Support 23 3.1 PKI-related Operations......................... 23 3.1.1 Authentication......................... 23 3.1.2 Session Key Establishment................... 24 3.1.3 Authentication with Session Key Establishment....... 24 3.1.4 Computation of Digital Signature............... 24 3.1.5 Encryption and Decryption.................. 24 3.1.6 Certificate Verification..................... 25 3.2 PKI-related Data Structure...................... 25 3.2.1 Overview............................ 25 3.2.2 Directory of Applications (EF.DIR).............. 27 3.2.3 Cryptographic Information Application (DF.CIA)...... 28 3.2.3.1 Overview....................... 28 3.2.3.2 CIA Information File (CIAInfo EF)......... 28 3.2.3.3 Object Directory File (EF.OD)........... 29 3.2.3.4 CIO Directory Files................. 30 3.3 Application Identification and Selection................ 33 3.3.1 Application Identification................... 33 3.3.2 Application Selection...................... 34 3.3.3 Common Scenarios....................... 34 3.4 Key/Password Storage and Retrieval................. 34 3.4.1 Passwords and Symmetric keys................ 34 3.4.2 Private Keys.......................... 36 3.4.3 Public Keys........................... 37 3.4.3.1 Retrieval of Public Key for VERIFY CERTIFI- CATE command................... 37 3.4.3.2 Retrieval of Public Key for Other Commands... 41 3.4.4 Common Scenarios....................... 41 3.5 Operations Supported in SCOSTA-PKI................ 42 3.5.1 Authentication......................... 42 3.5.1.1 External Authentication............... 42 3.5.1.2 Internal Authentication............... 44 3.5.1.3 Mutual Authentication................ 45 3.5.2 Session Key Establishment................... 47 3.5.3 Authentication and Session Key Establishment........ 48 3.6 Cryptographic Algorithms in SCOSTA-PKI............. 49 3.6.1 Algorithms for Confidentiality................. 51 3.6.2 Algorithms for Authentication................. 51 Contents vi 3.6.3 Algorithms for Digital Signature................ 52 3.7 SCOSTA-CL Commands Requiring Modifications in SCOSTA-PKI 52 3.7.1 ENVELOPE.......................... 53 3.7.2 GET CHALLENGE...................... 53 3.7.3 EXTERNAL/ INTERNAL/ MUTUAL AUTHENTICATE. 55 3.7.4 MSE SET for key derivation.................. 57 3.7.5 PSO DECIPHER........................ 59 3.7.6 PSO ENCIPHER........................ 60 3.7.7 PSO COMPUTE DIGITAL SIGNATURE.......... 61 3.7.8 PSO VERIFY CERTIFICATE................ 62 3.8 Additional Support for APDU in SCOSTA-PKI........... 63 4 Implementation 64 4.1 Support for Generic Data Objects................... 65 4.2 Extended Lc and Le.......................... 66 4.3 Application Identification and Selection................ 67 4.4 Storage and Retrieval of Cryptographic Information......... 68 4.5 Cryptographic Operations....................... 70 4.5.1 Encryption Schemes...................... 71 4.5.1.1 RSAES-PKCS1-v1 5 Scheme............ 71 4.5.1.2 RSAES-OAEP Scheme................ 72 4.6 Security Commands Modified..................... 72 4.7 Other Implementation Details..................... 72 4.7.1 Conversion from 2-byte EEPROM Address to a Generic EEPROM Address....................... 72 4.7.2 DES in Hardware........................ 73 5 Testing 74 6 Conclusion and Future Work 77 A ASN.1 module 81 A.1 Common Data Types.......................... 81 A.1.1 Path Data Type......................... 81 A.1.2 ObjectValue Data Type.................... 81 A.1.3 RSAPublicKey Data Type................... 82 A.1.4 RSAPrivateKey Data Type.................. 82 A.1.5 AlgorithmIdentifier Data Type................. 82 A.1.6 Name Data Type........................ 83 A.2 The CIO Type............................. 83 A.3 Keys................................... 84 A.3.1 Private Keys.......................... 85 A.3.2 Public Keys........................... 85 Contents vii A.3.3 Secret Keys........................... 86 A.4 Authentication Objects......................... 86 A.5 Certificates............................... 87 Bibliography 91 List of Figures 3.1 Chain certificate verification...................... 26 3.2 BER-TLV encoded structure of a DDO................ 28 3.3 Sample file structure.......................... 36 3.4 Protocol for authentication with session key establishment..... 50 4.1 Code organization............................ 64 viii List of Tables 3.1 Tags in application template...................... 27 3.2 Elementary files in DF.CIA...................... 28 3.3 Tags contained in a key template (tag `0xA0')............ 31 3.4 Mechanism for retrieval of Symmetric Keys and Passwords..... 35 3.5 Mechanism to obtain key reference for a private key......... 38 3.6 Mechanism to obtain key reference for a public key......... 39 3.7 Algorithm reference for confidentiality algorithms.......... 51 3.8 Algorithm reference
Recommended publications
  • Authentication in Key-Exchange: Definitions, Relations and Composition

    Authentication in Key-Exchange: Definitions, Relations and Composition

    Authentication in Key-Exchange: Definitions, Relations and Composition Cyprien Delpech de Saint Guilhem1;2, Marc Fischlin3, and Bogdan Warinschi2 1 imec-COSIC, KU Leuven, Belgium 2 Dept Computer Science, University of Bristol, United Kingdom 3 Computer Science, Technische Universit¨atDarmstadt, Germany [email protected], [email protected], [email protected] Abstract. We present a systematic approach to define and study authentication notions in authenti- cated key-exchange protocols. We propose and use a flexible and expressive predicate-based definitional framework. Our definitions capture key and entity authentication, in both implicit and explicit vari- ants, as well as key and entity confirmation, for authenticated key-exchange protocols. In particular, we capture critical notions in the authentication space such as key-compromise impersonation resis- tance and security against unknown key-share attacks. We first discuss these definitions within the Bellare{Rogaway model and then extend them to Canetti{Krawczyk-style models. We then show two useful applications of our framework. First, we look at the authentication guarantees of three representative protocols to draw several useful lessons for protocol design. The core technical contribution of this paper is then to formally establish that composition of secure implicitly authenti- cated key-exchange with subsequent confirmation protocols yields explicit authentication guarantees. Without a formal separation of implicit and explicit authentication from secrecy, a proof of this folklore result could not have been established. 1 Introduction The commonly expected level of security for authenticated key-exchange (AKE) protocols comprises two aspects. Authentication provides guarantees on the identities of the parties involved in the protocol execution.
  • 2.3 Diffie–Hellman Key Exchange

    2.3 Diffie–Hellman Key Exchange

    2.3. Di±e{Hellman key exchange 65 q q q q q q 6 q qq q q q q q q 900 q q q q q q q qq q q q q q q q q q q q q q q q q 800 q q q qq q q q q q q q q q qq q q q q q q q q q q q 700 q q q q q q q q q q q q q q q q q q q q q q q q q q qq q 600 q q q q q q q q q q q q qq q q q q q q q q q q q q q q q q q qq q q q q q q q q 500 q qq q q q q q qq q q q q q qqq q q q q q q q q q q q q q qq q q q 400 q q q q q q q q q q q q q q q q q q q q q q q q q 300 q q q q q q q q q q q q q q q q q q qqqq qqq q q q q q q q q q q q 200 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q qq q q qq q q 100 q q q q q q q q q q q q q q q q q q q q q q q q q 0 q - 0 30 60 90 120 150 180 210 240 270 Figure 2.2: Powers 627i mod 941 for i = 1; 2; 3;::: any group and use the group law instead of multiplication.
  • Elliptic Curves in Public Key Cryptography: the Diffie Hellman

    Elliptic Curves in Public Key Cryptography: the Diffie Hellman

    Elliptic Curves in Public Key Cryptography: The Diffie Hellman Key Exchange Protocol and its relationship to the Elliptic Curve Discrete Logarithm Problem Public Key Cryptography Public key cryptography is a modern form of cryptography that allows different parties to exchange information securely over an insecure network, without having first to agree upon some secret key. The main use of public key cryptography is to provide information security in computer science, for example to transfer securely email, credit card details or other secret information between sender and recipient via the internet. There are three steps involved in transferring information securely from person A to person B over an insecure network. These are encryption of the original information, called the plaintext, transfer of the encrypted message, or ciphertext, and decryption of the ciphertext back into plaintext. Since the transfer of the ciphertext is over an insecure network, any spy has access to the ciphertext and thus potentially has access to the original information, provided he is able to decipher the message. Thus, a successful cryptosystem must be able encrypt the original message in such a way that only the intended receiver can decipher the ciphertext. The goal of public key cryptography is to make the problem of deciphering the encrypted message too difficult to do in a reasonable time (by say brute-force) unless certain key facts are known. Ideally, only the intended sender and receiver of a message should know these certain key facts. Any certain piece of information that is essential in order to decrypt a message is known as a key.
  • Key Derivation Functions and Their GPU Implementation

    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).
  • Public Key Cryptography Public Key Cryptography

    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
  • The Double Ratchet Algorithm

    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.
  • Study on the Use of Cryptographic Techniques in Europe

    Study on the Use of Cryptographic Techniques in Europe

    Study on the use of cryptographic techniques in Europe [Deliverable – 2011-12-19] Updated on 2012-04-20 II Study on the use of cryptographic techniques in Europe Contributors to this report Authors: Edward Hamilton and Mischa Kriens of Analysys Mason Ltd Rodica Tirtea of ENISA Supervisor of the project: Rodica Tirtea of ENISA ENISA staff involved in the project: Demosthenes Ikonomou, Stefan Schiffner Agreements or Acknowledgements ENISA would like to thank the contributors and reviewers of this study. Study on the use of cryptographic techniques in Europe III About ENISA The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU leg- islation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu. Contact details For contacting ENISA or for general enquiries on cryptography, please use the following de- tails: E-mail: [email protected] Internet: http://www.enisa.europa.eu Legal notice Notice must be taken that this publication represents the views and interpretations of the au- thors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA Regulation (EC) No 460/2004 as lastly amended by Regulation (EU) No 580/2011.
  • On the Security of the PKCS#1 V1.5 Signature Scheme

    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.
  • PKCS #15— a Cryptographic-Token Information Format Standard

    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.
  • Public Key Infrastructure (PKI)

    Public Key Infrastructure (PKI)

    Public Key Infrastructure Public Key Infrastructure (PKI) Neil F. Johnson [email protected] http://ise.gmu.edu/~csis Assumptions • Understanding of – Fundamentals of Public Key Cryptosystems – Hash codes for message digests and integrity check – Digital Signatures Copyright 1999, Neil F. Johnson 1 Public Key Infrastructure Overview • Public Key Cryptosystems – Quick review – Cryptography – Digital Signatures – Key Management Issues • Certificates – Certificates Information – Certificate Authority – Track Issuing a Certificate • Putting it all together – PKI applications – Pretty Good Privacy (PGP) – Privacy Enhanced Mail (PEM) Public Key Cryptosystems – Quick Review • Key distribution problem of secret key systems – You must share the secret key with another party before you can initiate communication – If you want to communicate with n parties, you require n different keys • Public Key cryptosystems solve the key distribution problem in secret key systems (provided a reliable channel for communication of public keys can be implemented) • Security is based on the unfeasibility of computing B’s private key given the knowledge of – B’s public key, – chosen plaintext, and – maybe chosen ciphertext Copyright 1999, Neil F. Johnson 2 Public Key Infrastructure Key Distribution (n)(n-1) 2 Bob Bob Alice 1 Alice 2 Chris Chris 7 5 8 9 Ellie 3 Ellie 6 David 4 David Secret Key Distribution Directory of Public Keys (certificates) Public Key Cryptosystem INSECURE CHANNEL Plaintext Ciphertext Plaintext Encryption Decryption Algorithm Algorithm Bob’s PUBLIC
  • HSM SECURITY Securing PKCS#11 Interfaces

    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.
  • Introduction to Public Key Infrastructures

    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.