DOCSLIB.ORG

PKCS #11 V2.20: Cryptographic Token Interface Standard

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
PKCS #11 V2.20: Cryptographic Token Interface Standard PKCS #11 v2.20: Cryptographic Token Interface Standard RSA Laboratories 28 June 2004 Table of Contents 1 INTRODUCTION ............................................................................................................................ 1 2 SCOPE............................................................................................................................................... 2 3 REFERENCES.................................................................................................................................. 3 4 DEFINITIONS.................................................................................................................................. 7 5 SYMBOLS AND ABBREVIATIONS........................................................................................... 10 6 GENERAL OVERVIEW ............................................................................................................... 12 6.1 INTRODUCTION......................................................................................................................... 12 6.2 DESIGN GOALS ......................................................................................................................... 13 6.3 GENERAL MODEL ..................................................................................................................... 13 6.4 LOGICAL VIEW OF A TOKEN ...................................................................................................... 15 6.5 USERS ...................................................................................................................................... 16 6.6 APPLICATIONS AND THEIR USE OF CRYPTOKI ........................................................................... 17 6.6.1 Applications and processes ................................................................................................ 17 6.6.2 Applications and threads.................................................................................................... 18 6.7 SESSIONS.................................................................................................................................. 19 6.7.1 Read-only session states ..................................................................................................... 19 6.7.2 Read/write session states.................................................................................................... 20 6.7.3 Permitted object accesses by sessions ................................................................................ 21 6.7.4 Session events ..................................................................................................................... 22 6.7.5 Session handles and object handles.................................................................................... 23 6.7.6 Capabilities of sessions ...................................................................................................... 23 6.7.7 Example of use of sessions.................................................................................................. 24 6.8 SECONDARY AUTHENTICATION (DEPRECATED)........................................................................ 26 6.9 FUNCTION OVERVIEW............................................................................................................... 27 7 SECURITY CONSIDERATIONS ................................................................................................ 30 8 PLATFORM- AND COMPILER-DEPENDENT DIRECTIVES FOR C OR C++ ................. 31 8.1 STRUCTURE PACKING ............................................................................................................... 31 8.2 POINTER-RELATED MACROS ..................................................................................................... 32 ♦ CK_PTR .................................................................................................................................. 32 ♦ CK_DEFINE_FUNCTION...................................................................................................... 32 ♦ CK_DECLARE_FUNCTION .................................................................................................. 32 ♦ CK_DECLARE_FUNCTION_POINTER................................................................................ 32 Copyright 1994-2004 RSA Security Inc. License to copy this document is granted provided that it is identified as “RSA Security Inc. Public-Key Cryptography Standards (PKCS)” in all material mentioning or referencing this document. ii PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD ♦ CK_CALLBACK_FUNCTION ................................................................................................ 33 ♦ NULL_PTR.............................................................................................................................. 33 8.3 SAMPLE PLATFORM- AND COMPILER-DEPENDENT CODE........................................................... 33 8.3.1 Win32.................................................................................................................................. 33 8.3.2 Win16.................................................................................................................................. 34 8.3.3 Generic UNIX..................................................................................................................... 35 9 GENERAL DATA TYPES............................................................................................................. 36 9.1 GENERAL INFORMATION .......................................................................................................... 36 ♦ CK_VERSION; CK_VERSION_PTR ...................................................................................... 36 ♦ CK_INFO; CK_INFO_PTR .................................................................................................... 37 ♦ CK_NOTIFICATION .............................................................................................................. 38 9.2 SLOT AND TOKEN TYPES........................................................................................................... 38 ♦ CK_SLOT_ID; CK_SLOT_ID_PTR........................................................................................ 38 ♦ CK_SLOT_INFO; CK_SLOT_INFO_PTR.............................................................................. 39 ♦ CK_TOKEN_INFO; CK_TOKEN_INFO_PTR....................................................................... 40 9.3 SESSION TYPES ......................................................................................................................... 46 ♦ CK_SESSION_HANDLE; CK_SESSION_HANDLE_PTR ..................................................... 46 ♦ CK_USER_TYPE ....................................................................................................................46 ♦ CK_STATE .............................................................................................................................. 47 ♦ CK_SESSION_INFO; CK_SESSION_INFO_PTR.................................................................. 47 9.4 OBJECT TYPES .......................................................................................................................... 48 ♦ CK_OBJECT_HANDLE; CK_OBJECT_HANDLE_PTR ....................................................... 48 ♦ CK_OBJECT_CLASS; CK_OBJECT_CLASS_PTR ............................................................... 48 ♦ CK_HW_FEATURE_TYPE..................................................................................................... 49 ♦ CK_KEY_TYPE....................................................................................................................... 49 ♦ CK_CERTIFICATE_TYPE...................................................................................................... 50 ♦ CK_ATTRIBUTE_TYPE.......................................................................................................... 50 ♦ CK_ATTRIBUTE; CK_ATTRIBUTE_PTR.............................................................................. 51 ♦ CK_DATE................................................................................................................................ 51 9.5 DATA TYPES FOR MECHANISMS ................................................................................................ 52 ♦ CK_MECHANISM_TYPE; CK_MECHANISM_TYPE_PTR .................................................. 52 ♦ CK_MECHANISM; CK_MECHANISM_PTR......................................................................... 52 ♦ CK_MECHANISM_INFO; CK_MECHANISM_INFO_PTR .................................................. 53 9.6 FUNCTION TYPES...................................................................................................................... 54 ♦ CK_RV..................................................................................................................................... 55 ♦ CK_NOTIFY............................................................................................................................ 55 ♦ CK_C_XXX.............................................................................................................................. 55 ♦ CK_FUNCTION_LIST; CK_FUNCTION_LIST_PTR; CK_FUNCTION_LIST_PTR_PTR... 56 9.7 LOCKING-RELATED TYPES........................................................................................................ 58 ♦ CK_CREATEMUTEX.............................................................................................................
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]
  • By Jennifer M. Fogel a Dissertation Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy
    A MODERN FAMILY: THE PERFORMANCE OF “FAMILY” AND FAMILIALISM IN CONTEMPORARY TELEVISION SERIES by Jennifer M. Fogel A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Communication) in The University of Michigan 2012 Doctoral Committee: Associate Professor Amanda D. Lotz, Chair Professor Susan J. Douglas Professor Regina Morantz-Sanchez Associate Professor Bambi L. Haggins, Arizona State University © Jennifer M. Fogel 2012 ACKNOWLEDGEMENTS I owe my deepest gratitude to the members of my dissertation committee – Dr. Susan J. Douglas, Dr. Bambi L. Haggins, and Dr. Regina Morantz-Sanchez, who each contributed their time, expertise, encouragement, and comments throughout this entire process. These women who have mentored and guided me for a number of years have my utmost respect for the work they continue to contribute to our field. I owe my deepest gratitude to my advisor Dr. Amanda D. Lotz, who patiently refused to accept anything but my best work, motivated me to be a better teacher and academic, praised my successes, and will forever remain a friend and mentor. Without her constructive criticism, brainstorming sessions, and matching appreciation for good television, I would have been lost to the wolves of academia. One does not make a journey like this alone, and it would be remiss of me not to express my humble thanks to my parents and sister, without whom seven long and lonely years would not have passed by so quickly. They were both my inspiration and staunchest supporters. Without their tireless encouragement, laughter, and nurturing this dissertation would not have been possible.
    [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]
  • Harris Sierra II, Programmable Cryptographic
    TYPE 1 PROGRAMMABLE ENCRYPTION Harris Sierra™ II Programmable Cryptographic ASIC KEY BENEFITS When embedded in radios and other voice and data communications equipment, > Legacy algorithm support the Harris Sierra II Programmable Cryptographic ASIC encrypts classified > Low power consumption information prior to transmission and storage. NSA-certified, it is the foundation > JTRS compliant for the Harris Sierra II family of products—which includes two package options for the ASIC and supporting software. > Compliant with NSA’s Crypto Modernization Program The Sierra II ASIC offers a broad range of functionality, with data rates greater than 300 Mbps, > Compact form factor legacy algorithm support, advanced programmability and low power consumption. Its software programmability provides a low-cost migration path for future upgrades to embedded communications equipment—without the logistics and cost burden normally associated with upgrading hardware. Plus, it’s totally compliant with all Joint Tactical Radio System (JTRS) and Crypto Modernization Program requirements. The Sierra II ASIC’s small size, low power requirements, and high data rates make it an ideal choice for battery-powered applications, including military radios, wireless LANs, remote sensors, guided munitions, UAVs and any other devices that require a low-power, programmable solution for encryption. Specifications for: Harris SIERRA II™ Programmable Cryptographic ASIC GENERAL BATON/MEDLEY SAVILLE/PADSTONE KEESEE/CRAYON/WALBURN Type 1 – Cryptographic GOODSPEED Algorithms* ACCORDION FIREFLY/Enhanced FIREFLY JOSEKI Decrypt High Assurance AES DES, Triple DES Type 3 – Cryptographic AES Algorithms* Digital Signature Standard (DSS) Secure Hash Algorithm (SHA) Type 4 – Cryptographic CITADEL® Algorithms* SARK/PARK (KY-57, KYV-5 and KG-84A/C OTAR) DS-101 and DS-102 Key Fill Key Management SINCGARS Mode 2/3 Fill Benign Key/Benign Fill *Other algorithms can be added later.
    [Show full text]
  • 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]
  • An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext
    An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext By Isaac Quinn DuPont A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Faculty of Information University of Toronto © Copyright by Isaac Quinn DuPont 2017 ii An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext Isaac Quinn DuPont Doctor of Philosophy Faculty of Information University of Toronto 2017 Abstract Tis dissertation is an archeological study of cryptography. It questions the validity of thinking about cryptography in familiar, instrumentalist terms, and instead reveals the ways that cryptography can been understood as writing, media, and computation. In this dissertation, I ofer a critique of the prevailing views of cryptography by tracing a number of long overlooked themes in its history, including the development of artifcial languages, machine translation, media, code, notation, silence, and order. Using an archeological method, I detail historical conditions of possibility and the technical a priori of cryptography. Te conditions of possibility are explored in three parts, where I rhetorically rewrite the conventional terms of art, namely, plaintext, encryption, and ciphertext. I argue that plaintext has historically been understood as kind of inscription or form of writing, and has been associated with the development of artifcial languages, and used to analyze and investigate the natural world. I argue that the technical a priori of plaintext, encryption, and ciphertext is constitutive of the syntactic iii and semantic properties detailed in Nelson Goodman’s theory of notation, as described in his Languages of Art. I argue that encryption (and its reverse, decryption) are deterministic modes of transcription, which have historically been thought of as the medium between plaintext and ciphertext.
    [Show full text]
  • Cryptool 2 in Teaching Cryptography
    Journal of Computations & Modelling, vol.4, no.1, 2014, 349-358 ISSN: 1792-7625 (print), 1792-8850 (online) Scienpress Ltd, 2014 Cryptool 2 in Teaching Cryptography Major Konstantinos Loussios1 Abstract. Considering the value it had in the past, has continued to the present and will continue to have, perhaps to an even greater extent in the future concealing information during transmission or transport, leads automatically to attempt to discover the importance and the value of the means, methods and techniques used to implement the concealment. Cryptography is a branch of computer science attracts the attention with its great utility that has nowadays. Given therefore deemed necessary to standardize, analyze and present the encryption algorithms to learning and training on the operation with as efficiently and easily as possible. Having in mind that the theory must be accompanied by practice and examples that help to consolidate the syllabi material, we felt that the analytical presentation of an educational tool on learning algorithms of cryptography is a way of learning while embedding. The learning tool cryptool 2 is an implementation of all the above, and through this we will try to show, those essential functions, which help the user with visual and practical way, to see in detail all the properties and functional details of the algorithms contained, will present representative examples of functioning algorithms, we proceed to create digital signatures and will implement the cryptanalysis algorithms. The above is an object of study and teaching in the professional area of land, in the field of communications and transmissions-service systems. Knowing, however, that historically since the antiquity, first we Greeks, we use encryption in a simple form, for military purposes, but later down through the years and fighting wars around the world, the art encryption and decryption evolved and became object of all armies and weapons.
    [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]