DOCSLIB.ORG

Pkcs Pkcs 1 Pkcs 1 Pkcs 1 Pkcs 1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Pkcs Pkcs 1 Pkcs 1 Pkcs 1 Pkcs 1 INFS 766 PKCS 1 Internet Security Protocols v Specifies how to use the RSA Lecture 10 algorithm securely for encryption PKCS and signature v Why do we need this? Ø Padding for encryption Ø Different schemes for signature Prof. Ravi Sandhu © Ravi Sandhu 2002 4 PKCS PKCS 1 v Public-key cryptography standards (PKCS) v Chosen ciphertext attack based on v Owned by RSA and motivated to promote multiplicative property of RSA RSA Ø Attacker wishes to decrypt c v Created in early 1990’s Ø Choose r, compute c’ = c.re mod n v Numbered from PKCS1 to PKCS15 Ø Get victim to decrypt c’ giving cd.r mod n v Some along the way have Ø cd.r.r -1 mod n = cd mod n Ø lost interest v Padding destroys multiplicative Ø folded into other PKCS property Ø taken over by other standards bodies v Continue to evolve © Ravi Sandhu 2002 2 © Ravi Sandhu 2002 5 PKCS 1 PKCS 1 v RSA Cryptography Standard v Version 1.5, 1993 Ø Version 2.0 onwards (1998) Ø Encryption padding was found defective v RSA Encryption Standard in 1998 by Bleichenbacher Ø Possible to generate valid ciphertext Ø Version 1.5 (1993) without knowing corresponding plaintext with reasonable probability of success (chosen ciphertext) © Ravi Sandhu 2002 3 © Ravi Sandhu 2002 6 PKCS 1 PKCS 1 v Version 2.0, 1998 v Encryption scheme Ø Uses Optimal asymmetric encryption protocol (OAEP) Ø Combines encryption primitive with an encryption by Bellare-Rogoway 1994 encoding method • provably secure in the random oracle model Ø message à encoded message à integer message • Informally, if hash functions are truly random, then an representative à encrypted message adversary who can recover such a message must be able v Decryption scheme to break RSA Ø • plaintext-awareness: to construct a valid OAEP encoded Combines decryption primitive with a decryption message, an adversary must know the original plaintext decoding method Ø PKCS 1 version 1.5 padding continues to be allowed for Ø encrypted message à integer message representative backward compatibility à encoded message à message Ø Accommodation for multi-prime RSA v Original version 1.5 scheme and new version 2.0 • Speed up private key operations scheme © Ravi Sandhu 2002 7 © Ravi Sandhu 2002 10 PKCS 1 PKCS 1 v Cryptographic primitives v Signature scheme Ø Combines signature primitive with a signature encoding v Cryptographic scheme method Ø Encryption scheme Ø message à encoded message à integer message Ø Signature scheme representative à signature • Signature with appendix: supported v Decryption scheme • Signature with message recovery: not supported Ø Combines verification primitive with a verification decoding method v Encoding and decoding Ø signature à integer message representative à encoded Ø Converting an integer message into an octet message à message string for use in encryption or signature v Original version 1.5 scheme scheme and vice versa Ø Signature with appendix © Ravi Sandhu 2002 8 © Ravi Sandhu 2002 11 PKCS 1 PKCS 1 v Cryptographic primitives v The future Ø Encrypt RSAEP((n,e),m) v Probabilistic signature scheme (PSS) Ø Provably secure in random oracle model Ø Decrypt RSADP((n,d),c) Ø Natural extension to message recovery Ø Sign RSASP1((n,d),m) Ø Verify RSAVP1((n,e),s) v Basically exponentiation with differently named inputs © Ravi Sandhu 2002 9 © Ravi Sandhu 2002 12 PKCS 5 PKCS 5 v Password-Based Cryptography v Version 2.0 adds PBKDF2 Standard Ø Arbitrary length key Ø Version 1.5, 1993 Ø Any underlying hash function, most likely Ø Version 2.0, 1999 with HMAC v Oriented towards protection of Ø Salt not fixed at 8 bytes private keys Ø Provable security in random oracle model v Does not specify a standard for password format © Ravi Sandhu 2002 13 © Ravi Sandhu 2002 16 PKCS 5 PKCS 5 v Password-based key derivation function v Encryption schemes Ø Key = PBKDF(passwd, salt, iteration count) Ø PBES1 v salt allows same password to give many • PBKDF1 with DES or RC2 in CBC keys Ø PBES2 • PBKDF2 with some underlying encryption Ø May actually have same password scheme Ø Separate dictionary attack for every salt v MAC scheme v Iteration count controls complexity of dictionary attack Ø PBMAC1 • PBKDF2 with some underlying MAC scheme © Ravi Sandhu 2002 14 © Ravi Sandhu 2002 17 PKCS 5 PKCS 10 v Version 1.5 PBKDF1 v Certification Request Syntax Standard Ø Key size limited to 160 bits v Specifies format of unsigned Ø Only MD5 and SHA as underlying hash certificate requested to be signed functions v Does not specify format of returned Ø Assumes key will be used for CBC signed certificate Ø 8-byte salt Ø No security proof © Ravi Sandhu 2002 15 © Ravi Sandhu 2002 18 PKCS 10 PKCS 8 v Version 1.0, 1993 v Private-Key Information Syntax Ø In widespread use Standard v Version 1.5, 1998 Ø Version 1.2, 1993 v Version 1.7, 2000 Ø Minor changes such as references to PKCS 6 replaced by references to X.509v3 © Ravi Sandhu 2002 19 © Ravi Sandhu 2002 22 PKCS 10 PKCS 8 v CertificationRequestInfo v PrivateKeyInfo Ø version Ø version Ø subjectName Ø privateKeyAlgorithm Ø subjectPublicKeyInfo Ø privateKey Ø attributes Ø attributes © Ravi Sandhu 2002 20 © Ravi Sandhu 2002 23 PKCS 10 PKCS 8 v CertificationRequest v encryptedPrivateKeyInfo Ø certificationRequestInfo Ø encryptionAlgorithm Ø signatureAlgorithm Ø encryptedData Ø signature • privateKeyInfo BER-encoded and encrypted v Signed with private key corresponding to v Usually encrypted using PKCS 5 public key in request Ø very RSA specific Ø IETF RFC 2511 defines a different format: certificate request message format © Ravi Sandhu 2002 21 © Ravi Sandhu 2002 24 PKCS 12 PKCS 12 v Personal Information Exchange v The entire stuff is then either Syntax Standard Ø Signed • And accompanied with signing certificate Ø Version 1, 1999 Ø MAC’ed v Builds on PKCS 8 • PKCS 5 based and accompanied with salt v Further evolution PKCS 15 and iteration count v Notice: opposite of usual sequence Ø Encrypt and then authenticate, versus Ø Authenticate and then encrypt © Ravi Sandhu 2002 25 © Ravi Sandhu 2002 28 PKCS PKCS 12 DISCONTINUED OR DISINTERESTED v 6 types of information v PKCS 2 Ø PKCS 8 shrouded key Ø discontinued, incorporated into PKCS 1 Ø Private key Ø Certificates v PKCS 3 • X.509v3 Ø Diffie-Hellman Key Agreement, 1993 • SDSI Ø CRLs v PKCS 4 • X.509 Ø discontinued, incorporated into PKCS 1 Ø Secret • Whatever Ø Recursive composition of these © Ravi Sandhu 2002 26 © Ravi Sandhu 2002 29 PKCS PKCS 12 TAKEN OVER BY OTHERS v Each of these can be v PKCS 6 Ø Plaintext Ø Extended Certificate Syntax Standard Ø Enveloped Ø Taken over by X.509v3 • Encrypted using a secret key which is encrypted using a public key v PKCS 7 Ø Encrypted Ø Cryptographic Message Syntax • Secret key encrypted Standard • Usually password derived Ø Taken over by IETF PKIX CMS – Use PKCS 5 and a password formatting standard which is part of PKCS 12 © Ravi Sandhu 2002 27 © Ravi Sandhu 2002 30 PKCS 9 PKCS 11 vs PKCS 15 Crypto Application v PKCS 9 (Browser, email client etc) Ø Selected Attribute Types Ø For use in PKCS 6, 7, 8, 10 Standard Crypto API (PKCS 11, CSP, etc) Cryptographic Token Information Format Standard (PKCS 15) © Ravi Sandhu 2002 31 © Ravi Sandhu 2002 34 PKCS 11 v PKCS 11 Ø Cryptographic Token Interface Standard Ø API used by Netscape (pre 6.0) Ø Microsoft CSP (Cryptographic Service Provider) is a competitor © Ravi Sandhu 2002 32 PKCS IN DEVELOPMENT v PKCS 13 (new, in development) Ø Elliptic Curve Cryptography Standard Ø There are IEEE standards, so not clear why v PKCS 14 (new, in development) Ø Pseudorandom Number Generation Standard v PKCS 15 (new, in development) Ø Cryptographic Token Information Format Standard Ø Crypto API neutral © Ravi Sandhu 2002 33.
Load more

Recommended publications
  • IBM® Z/OS® Version 1 Release 12 System SSL Cryptographic Module
    z/OS Version 1 Release 12 System SSL Security Policy IBM® z/OS® Version 1 Release 12 System SSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Policy Version 1.01 IBM Systems & Technology Group System z Development Poughkeepsie, New York IBM Research Zurich Research Laboratory August 24, 2011 © Copyright International Business Machines Corporation 2011 This document may be reproduced only in its original entirety without revision. © Copyright IBM Corp. 2011 Page 1 of 31 z/OS Version 1 Release 12 System SSL Security Policy Table of Contents 1 SCOPE OF DOCUMENT .............................................................................................................................................................3 2 CRYPTOGRAPHIC MODULE SPECIFICATION...................................................................................................................4 3 CRYPTOGRAPHIC MODULE SECURITY LEVEL ...............................................................................................................5 4 PORTS AND INTERFACES ........................................................................................................................................................6 5 ROLES, SERVICES AND AUTHENTICATION.......................................................................................................................6 5.1 ROLES ......................................................................................................................................................................................6
    [Show full text]
  • Security + Encryption Standards
    Security + Encryption Standards Author: Joseph Lee Email: joseph@ ripplesoftware.ca Mobile: 778-725-3206 General Concepts Forward secrecy / perfect forward secrecy • Using a key exchange to provide a new key for each session provides improved forward secrecy because if keys are found out by an attacker, past data cannot be compromised with the keys Confusion • Cipher-text is significantly different than the original plaintext data • The property of confusion hides the relationship between the cipher-text and the key Diffusion • Is the principle that small changes in message plaintext results in large changes in the cipher-text • The idea of diffusion is to hide the relationship between the cipher-text and the plaintext Secret-algorithm • A proprietary algorithm that is not publicly disclosed • This is discouraged because it cannot be reviewed Weak / depreciated algorithms • An algorithm that can be easily "cracked" or defeated by an attacker High-resiliency • Refers to the strength of the encryption key if an attacker discovers part of the key Data-in-transit • Data sent over a network Data-at-rest • Data stored on a medium Data-in-use • Data being used by an application / computer system Out-of-band KEX • Using a medium / channel for key-exchange other than the medium the data transfer is taking place (phone, email, snail mail) In-band KEX • Using the same medium / channel for key-exchange that the data transfer is taking place Integrity • Ability to determine the message has not been altered • Hashing algorithms manage Authenticity
    [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]
  • ONVIF™ Advanced Security Test Specification
    ONVIF Advanced Security Test Specification Version 17.06 ONVIF™ Advanced Security Test Specification Version 17.06 June 2017 www.onvif.org ONVIF Advanced Security Test Specification Version 17.06 © 2017 ONVIF, Inc. All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 2 www.onvif.org ONVIF Advanced Security Test Specification Version 17.06 REVISION HISTORY Vers.
    [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]
  • Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms
    Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms Contents Introduction Background Information Prerequisites Requirements Components Used Problem Solution Verification Introduction This document describes how to troubleshoot the installation failure of a Public Key Cryptography Standards (PKCS)#12 file with non-Federal Information Processing Standard (FIPS) compliant Password-Based Encryption (PBE) algorithms via Cisco Firepower Management Center (FMC). It explains a procedure to identify it and to create a new compliant bundle with OpenSSL. Background Information The Cisco Firepower Threat Defense (FTD) supports compliance with FIPS 140 when you enable Common Criteria (CC) or Unified Capabilities Approved Products List (UCAP) mode on a managed device. This configuration is part of a FMC Platform Settings policy. After applied, the fips enable command appears in the show running-config output of FTD. PKCS#12 defines a file format used to bundle a private key and the respective identity certificate. There is the option to include any root or intermediate certificate that belongs to the validation chain as well. PBE algorithms protect the certificates and private key portions of the PKCS#12 file. As a result of the combination of the Message Authentication Scheme (MD2/MD5/SHA1) and the Encryption scheme (RC2/RC4/DES), there are multiple PBE algorithms but the only one that is FIPS compliant is PBE-SHA1-3DES. Note: To learn more about FIPS in Cisco products navigate to FIPS 140. Note: To learn more about the security certifications standards available for FTD and FMC navigate to the Security Certifications Compliance chapter of the FMC Configuration Guide.
    [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]
  • SSL Certificates Avi Networks — Technical Reference (18.1)
    Page 1 of 6 SSL Certificates Avi Networks — Technical Reference (18.1) SSL Certificates view online Avi Vantage supports terminating client SSL and TLS connections at the virtual service. This requires Avi Vantage to send a certificate to clients that authenticates the site and establishes secure communications. A virtual service that handles secure connections will require both of the following: SSL/TLS profile: Determines the supported ciphers and versions. See SSL Profile. SSL certificate: A certificate is presented to clients connecting to the site. SSL certificates may also be used to present to administrators connecting to the Avi Vantage web interface or API, and also for Avi Service Engines to present to servers when SE-to-server encryption is required with client (the SE) authentication. The SSL Certifications tab on the Templates > Security page shown below supports import, export, and generation of SSL certificates or certificate requests. From this page different kinds of certificates may be created: Newly-created certificates may be either self-signed by Avi Vantage or created as a certificate signing request (CSR) that must be sent to a trusted certificate authority (CA), which then generates a trusted certificate. Creating a self-signed certificate generates both the certificate and a corresponding private key. Imported existing certificates are not valid until a matching key has been supplied. Avi Vantage supports PEM and PKCS #12 formatted certificates. Copyright © 2018 Avi Networks, Inc. Page 2 of 6 SSL Certificates Avi Networks — Technical Reference (18.1) SSL/TLS Certificates Page Select Templates > SSL/TLS Certificates to open the SSL/TLS Certificates page.
    [Show full text]