Encryption and Decryption

Total Page:16

File Type:pdf, Size:1020Kb

Encryption and Decryption Security Toolkit Version 2.1 final beta Copyright Peter Gutmann 1992-1999 March 1999 2 Introduction INTRODUCTION 10 cryptlib Overview 10 cryptlib features 11 Programming Interface 11 Security Features 11 Standards Compliance 12 Y2K Compliance 12 Performance 12 Encrypted Object Management 12 Certificate Management 13 Key Database Interface 13 Smart Card Support 14 Cryptographic Random Number Management 14 Configuration Options 14 Document conventions 14 Recommended Reading 15 INSTALLATION 16 Installing cryptlib for Windows 3.x 16 Installing cryptlib for Windows’95/98 and Windows NT 16 Installing from Source Code 16 BeOS 16 DOS 16 DOS32 16 OS2 16 Windows 3.x 17 Windows’95/98 and Windows NT 17 Unix 17 Other systems 18 Key Database Setup 19 Certificate Installation 19 Cut-down cryptlib Versions 19 Support for Vendor-specific Algorithms 20 CRYPTLIB BASICS 21 Programming interfaces 21 Envelope interface 22 Encryption object interface 22 Low-level interface 22 Objects and Interfaces 22 Interfacing with cryptlib 23 Initialisation 23 Additional Initialisation 23 Interaction with External Events 23 Object Security 24 ENVELOPING CONCEPTS 27 Creating/Destroying Envelopes 27 The Data Enveloping Process 28 Data Size Considerations 29 Basic Data Enveloping 30 Password-based Encryption Enveloping 30 De-enveloping Mixed Data 31 Enveloping Large Data Quantities 32 cryptlib Overview 3 Alternative Processing Techniques 33 Enveloping with Many Resources 34 ADVANCED ENVELOPING 36 Public-Key Encrypted Enveloping 36 Digitally Signed Enveloping 37 Enveloping with Multiple Resources 39 Envelope Resource Cursor Management 39 Processing Multiple Resources 40 Nested Envelopes 41 KEY DATABASES 43 Creating/Destroying Keyset Objects 43 File Keysets 44 LDAP Keysets 45 Relational Database Keysets 46 Smart Card Keysets 47 Extended Keyset Initialisation 48 LDAP Keysets 49 Relational Database Keysets 49 Smart Card Keysets 50 Accessing a Keyset 52 Reading a Key from a Keyset 52 Obtaining a Key for a User 53 Obtaining a Key for an Exported Key/Signature/Certificate Object 54 Writing a Key to a Keyset 55 General Keyset Queries 56 Deleting a Key 58 ENCRYPTION AND DECRYPTION 59 Creating/Destroying Encryption Contexts 59 Extended Initialization 60 Generating a Key into an Encryption Context 60 Public/Private Key Generation 61 Deriving a Key into an Encryption Context 62 Loading Keys into Encryption Contexts 63 Loading Initialisation Vectors 63 Working with Public/Private Keys 64 Multibyte Integer Formats 64 Loading Multibyte Integers 65 ENCRYPTING/DECRYPTING DATA 67 Using Encryption Contexts to Encrypt/Decrypt Data 67 EXCHANGING KEYS 69 Exporting a Key 69 Exporting using Conventional Encryption 70 Importing a Key 71 Importing using Conventional Encryption 71 Querying an Exported Key Object 72 Conventionally encrypted objects 72 Public-key encrypted objects 73 Extended Key Export/Import 73 Key Agreement 74 4 Introduction SIGNING DATA 76 Querying a Signature Object 77 Extended Signature Creation/Checking 78 CERTIFICATE MANAGEMENT 80 Overview of Certificates 80 Certificates and Standards Compliance 80 The Certification Process 81 Creating/Destroying Certificate Objects 82 Working with Certificate Components 82 Component Types 83 Querying/Setting/Deleting Components 83 Certificate Structures 84 Attribute Certificate Structure 85 Certificate Structure 86 Certification Request Structure 88 CRL Structure 88 Basic Certificate Management 89 Certificate Identification Information 91 DN Structure for Business Use 92 DN Structure for Private Use 92 Other DN Structures 93 Working with Distinguished Names 93 Extended Certificate Identification Information 93 Working with GeneralNames 94 Certificate Fingerprints 95 Importing/Exporting Certificates 95 Signing/Verifying Certificates 97 Certificate Trust Management 99 Working with Trust Settings 100 Certificate Errors 100 CERTIFICATE EXTENSIONS 102 Extension Structure 102 Working with Extension Components 102 Extension Cursor Management 103 Composite Extension Fields 105 X.509 Extensions 106 Alternative Names 106 Basic Constraints 106 Certificate Policies, Policy Mappings, and Policy Constraints 107 CRL Distribution Points and Authority Information Access 108 Directory Attributes 108 Key Usage, Extended Key Usage, and Netscape cert-type 108 Name Constraints 111 Private Key Usage Period 112 Subject and Authority Key Identifiers 112 CRL Extensions 113 CRL Reasons, CRL Numbers, Delta CRL Indicators 113 Hold Instruction Code 114 Invalidity Date 114 Issuing Distribution Point and Certificate Issuer 114 SET Extensions 115 SET Card Required and Merchant Data 115 SET Certificate Type, Hashed Root Key, and Tunneling 115 cryptlib Overview 5 Vendor-specific Extensions 116 Netscape Certificate Extensions 116 Thawte Certificate Extensions 117 MAINTAINING KEYS AND CERTIFICATES 118 Updating a Private Key with Certificate Information 118 The Certification Process 119 Certificate Chains 121 Working with Certificate Chains 121 Signing Certificate Chains 122 Checking Certificate Chains 123 Exporting Certificate Chains 124 Certificate Revocation Lists 124 Working with CRL’s 124 Creating CRL’s 125 Advanced CRL Creation 126 Checking Certificates against CRL’s 126 Automated CRL Checking 127 FURTHER CERTIFICATE OBJECTS 128 Certificate-like Object Structure 128 CMS Attributes 128 CMS Attributes 128 Content Type 128 Countersignature 129 MAC Value 129 Message Digest 129 Signing Time 130 Extended CMS Attributes 130 AuthentiCode Attributes 130 Content Hints 131 Mail List Expansion History 131 Receipt Request 131 Security Label, Equivalent Label 132 Signing Certificate 133 S/MIME 134 S/MIME Enveloping 134 Encrypted Enveloping 135 Digitally Signed Enveloping 135 Detached Signatures 136 Extra Signature Information 137 From Envelopes to S/MIME 138 S/MIME Content Types 139 Data 139 Signed Data 139 Detached Signature 139 Encrypted Data 140 Nested Content 140 Implementing S/MIME using cryptlib 140 Example: Eudora 140 ENCRYPTION DEVICES AND MODULES 142 Creating/Destroying Device Objects 142 Activating and Controlling Cryptographic Devices 143 Initialise Device 143 6 Introduction User Authentication 143 Zeroise Device 143 Extended Device Control Functions 144 Setting/Changing User Authentication Values 144 Working with Device Objects 144 Considerations when Working with Devices 145 PKCS #11 Devices 145 Installing New PKCS #11 Modules 146 PKCS #11 Functions used by cryptlib 146 RANDOM NUMBERS 147 Gathering Random Information 147 Random Information Gathering Techniques 147 BeOS 148 DOS 148 Macintosh 148 OS/2 149 UNIX 149 Windows 3.x 150 Windows 95 150 Windows NT 150 Hardware Random Number Generation 151 MISCELLANEOUS TOPICS 153 Querying cryptlib’s Capabilities 153 Working with Configuration Options 153 Configuration Option Types 154 Querying/Setting Configuration Options 154 Storing/Retrieving Configuration Options 155 Obtaining Information About Cryptlib 155 Working with Newer Versions of cryptlib 156 ERROR HANDLING 157 Extended Error Reporting 159 ALGORITHMS AND MODES 161 Blowfish 161 CAST-128 161 DES 161 Triple DES 161 Diffie-Hellman 162 DSA 162 ElGamal 162 HMAC-MD5 162 HMAC-SHA1 162 HMAC-RIPEMD-160 162 IDEA 162 MD2 163 MD4 163 MD5 164 MDC2 164 RC2 164 RC4 164 cryptlib Overview 7 RC5 164 RIPEMD-160 164 RSA 164 SAFER 165 SAFER-SK 165 SHA 165 Skipjack 165 ECB 165 CBC 165 CFB 165 OFB 165 DATA TYPES AND CONSTANTS 170 CRYPT_ALGO 170 CRYPT_CERTERROR_TYPE 171 CRYPT_CERTFORMAT_TYPE 171 CRYPT_CERTINFO_TYPE 172 CRYPT_CERTTYPE_TYPE 172 CRYPT_DEVICE_TYPE 172 CRYPT_DEVICECONTROL_TYPE 173 CRYPT_ENVINFO_TYPE 173 CRYPT_FORMAT_TYPE 174 CRYPT_KEYID_TYPE 174 CRYPT_KEYOPT 174 CRYPT_KEYSET_TYPE 179 CRYPT_MODE 179 CRYPT_OBJECT_TYPE 180 CRYPT_OPTION_TYPE 180 CRYPT_PROPERTY_TYPE 184 Data Size Constants 184 Miscellaneous Constants 185 DATA STRUCTURES 186 CRYPT_INFO Structures 186 CRYPT_OBJECT_INFO Structure 186 CRYPT_PKCINFO Structures 187 CRYPT_QUERY_INFO Structure 188 FUNCTION REFERENCE 189 cryptAddCertComponentNumeric 189 cryptAddCertComponentString 189 cryptAddCertExtension 189 cryptAddEnvComponentNumeric 190 cryptAddEnvComponentString 190 cryptAddPrivateKey 191 cryptAddPublicKey 191 cryptAddRandom 191 cryptAsyncCancel 192 cryptAsyncQuery 192 8 Introduction cryptCheckCert 192 cryptCheckSignature 192 cryptCheckSignatureEx 193 cryptCreateCert 193 cryptCreateContext 193 cryptCreateContextEx 194 cryptCreateDeenvelope 195 cryptCreateDeenvelopeEx 195 cryptCreateEnvelope 195 cryptCreateEnvelopeEx 195 cryptCreateSignature 196 cryptCreateSignatureEx 196 cryptDecrypt 197 cryptDeleteCertComponent 197 cryptDeleteCertExtension 198 cryptDeleteKey 198 cryptDeriveKey 198 cryptDeriveKeyEx 199 cryptDestroyCert 199 cryptDestroyContext 200 cryptDestroyEnvelope 200 cryptDestroyObject 200 cryptDeviceClose 200 cryptDeviceControl 201 cryptDeviceControlEx 201 cryptDeviceCreateContext 201 cryptDeviceOpen 202 cryptDeviceOpenEx 202 cryptEncrypt 202 cryptEnd 203 cryptExportCert 203 cryptExportKey 203 cryptExportKeyEx 204 cryptGenerateKey 205 cryptGenerateKeyAsync 205 cryptGenerateKeyEx 205 cryptGenerateKeyAsyncEx 206 cryptGetCertComponentNumeric 206 cryptGetCertComponentString 206 cryptGetCertExtension 207 cryptGetEnvComponentNumeric 207 cryptGetErrorInfo 208 cryptGetErrorMessage 208 cryptGetObjectProperty 208 cryptGetOptionNumeric 209 cryptGetOptionString 209 cryptGetPrivateKey 209 cryptlib Overview 9 cryptGetPublicKey 210 cryptGetRandom 210 cryptImportCert 211 cryptImportKey 211 cryptImportKeyEx 211 cryptInit 212 cryptInitEx 212 cryptKeysetClose 212 cryptKeysetOpen 213 cryptKeysetOpenEx 213 cryptKeysetQuery 213
Recommended publications
  • Treasury X.509 Certificate Policy [TREASURYCP].” It Only Addresses Where an OLT PKI’S Requirements Differ from the Requirements for Basic Assurance in [TREASURYCP]
    UNCLASSIFIED UNITED STATES DEPARTMENT OF THE TREASURY DEPARTMENT OF THE TREASURY PUBLIC KEY INFRASTRUCTURE (PKI) X.509 CERTIFICATE POLICY VERSION 3.4 April 27, 2021 PKI Policy Management Authority (PMA) DATE DANIEL W. WOOD 1 UNCLASSIFIED DOCUMENT VERSION CONTROL Version Date Author(s) Description Reason For Change Bring the Treasury PKI Policy into Department of the compliance with FPKIPA change Treasury PKI Policy in 2.0 January 2008 James Schminky proposal requiring all cross certified RFC PKI Policies to be in RFC 3647 3647 format. format. As a result of mapping the Treasury Errata changes to sections PKI Policy to Federal Policy, a 2.2.1, 2.1 March 17, 2009 James Schminky number of minor changes and 4.8, 4.912, 5.5, and omissions where identified and 7.1.3. corrected. As a result of the PMA annual Errata changes to sections review a number of minor 5.6, and 6.3.2. Change corrections, Federal Bridge proposal changes to 2.4, 2.2 March 11, 2010 James Schminky Certification Authority (FBCA) 4.2.2, 5.1, 5.1.1 5.1.2.1, Policy Change Proposal Number: 5.4.4, 5.4.5, 6.1.6, 6.5.1, 2009-02 and 2010-01, and Treasury and 6.7. Change Proposal Change proposal changes As a result of FBCA Policy Change 2.3 April 15, 2010 James Schminky to 8.1 and 8.4. Proposal Number: 2010-02. Changes Proposal As a result of FBCA Policy Change Changes to 1.3.1.8, Proposal Numbers; 2010-3 thru 8 2.4 March 22, 2011 James Schminky 3.1.1&.2, 3.1.5, 3.2.3.1, and CPCA policy Change Proposal 4.7, 6.1.5, 8.1, and 9.4.3.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • A Focus on S/MIME
    The University of Saskatchewan Department of Computer Science Technical Report #2011-03 Cryptographic Security for Emails: A Focus on S/MIME Minhaz Fahim Zibran Department of Computer Science University of Saskatchewan Email: [email protected] Abstract In this paper I present a study on \S/MIME", which has become the industry standard for secure email exchange. Based on existing literature review, the study examines S/MIME in depth with specific emphasis on its architecture, strengths, and deficiencies. The study also identifies usability issues related to S/MIME enabled email clients, which indicate scopes for further improvements in those implementations. Obstacles in the adoption of S/MIME are also identified indicating what is required for its successful adoption in the community. In presenting the study, the paper contributes in two ways: (a) for any newcomer in the field of cryptography this paper will be a useful resource to quickly learn about S/MIME in a fair level of detail, (b) the indication about limitations of S/MIME and its implementations reveals an avenue for further research in the area of email security, which may result in improvement of S/MIME itself, or its implementations in the email clients. Keywords: Email Security, S/MIME, MIME, PGP, PKI, Certificate, Email Authentication, Email Encryption, Key Management 1 Introduction Email has been a very common medium of communication these days. It somewhat re- places the traditional surface mail and many of the traditional ways of communication [32]. Today people send and read emails from their personal computers, business workstation, PDAs and even cell phones.
    [Show full text]
  • Towards a Hybrid Public Key Infrastructure (PKI): a Review
    Towards a Hybrid Public Key Infrastructure (PKI): A Review Priyadarshi Singh, Abdul Basit, N Chaitanya Kumar, and V. Ch. Venkaiah School of Computer and Information Sciences, University of Hyderabad, Hyderabad-500046, India Abstract. Traditional Certificate- based public key infrastructure (PKI) suffers from the problem of certificate overhead like its storage, verification, revocation etc. To overcome these problems, idea of certificate less identity-based public key cryptography (ID-PKC) was proposed by Shamir. This is suitable for closed trusted group only. Also, this concept has some inherent problems like key escrow problem, secure key channel problem, identity management overhead etc. Later on, there had been several works which tried to combine both the cryptographic techniques such that the resulting hybrid PKI framework is built upon the best features of both the cryptographic techniques. It had been shown that this approach solves many problems associated with an individual cryptosystem. In this paper, we have reviewed and compared such hybrid schemes which tried to combine both the certificate based PKC and ID-based PKC. Also, the summary of the comparison, based on various features, is presented in a table. Keywords: Certificate-based PKI; Identity-based public key cryptography (ID-PKC); Hybrid PKI 1 INTRODUCTION Public key infrastructure (PKI) and public key cryptography (PKC) [12] plays a vital role with four major components of digital security: authentication, integrity, confidentiality and non-repudiation. Infact, PKI enables the use of PKC through key management. The ”efficient and secure management of the key pairs during their whole life cycle" is the purpose of PKI, which involves key generation, key distribution, key renewal, key revocation etc [11].
    [Show full text]
  • Security Target Document
    Security Target Document Passport Certificate Server Ver. 4.1.1 Prepared for: Common Criteria EAL2 (augmented) 30 April 2002 2225 Sheppard Ave, Suite 1700 Toronto, Ontario, Canada M2J 5C2 TEL: 416-756-2324 FAX: 416-756-7346 [email protected] www.dvnet.com Passport Certificate Server V.4.1.1 Security Target 30 April 2002 Common Criteria EAL 2 (augmented) Version 1.00 TABLE OF CONTENTS 1 Introduction ............................................................................................................................................ 1 1.1 Security Target Identification......................................................................................................... 1 1.2 Security Target Overview............................................................................................................... 1 1.3 Common Criteria Conformance .....................................................................................................1 2 TOE Description..................................................................................................................................... 2 2.1 Product Deployment....................................................................................................................... 2 2.2 Product Functions........................................................................................................................... 2 2.3 Product Description ........................................................................................................................ 3 2.3.1 Platform
    [Show full text]
  • Implementing PKI Services on Z/OS
    Front cover Implementing PKI Services on z/OS Installation of PKI and all of its prerequistes on z/OS An example of the PKI Exit PKI’s use of ICSF to store Master Key Chris Rayns Theo Antoff Jack Jones Patrick Kappeler Vicente Ranieri Roland Trauner ibm.com/redbooks International Technical Support Organization Implementing PKI Services on z/OS February 2004 SG24-6968-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (February 2004) This edition applies to z/OS Version 1, Release 3. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this redbook. ix Become a published author . x Comments welcome. xi Chapter 1. Security Server PKI Services. 1 1.1 Overview of digital certificate. 2 1.2 The PKIX standards . 4 1.2.1 CA hierarchy . 6 1.2.2 The X.509 certificate and Certificate Revocation List . 9 1.2.3 The x.509 v3 certificate extension fields . 14 1.2.4 Certificate and CRL appearance. 17 1.3 The z/OS PKI Services . 21 1.3.1 Security Server PKI Services in z/OS . 21 1.3.2 Prerequisite products . 22 1.3.3 Requests supported by z/OS PKI Services. 23 1.3.4 Browser and server certificates. 24 1.3.5 The z/OS PKI Services architecture . 26 1.4 Security Server PKI Services enhancement in z/OS V1R4.
    [Show full text]
  • Amazon Trust Services Certificate Policy
    Certificate Policy Version 1.0.9 1 1 INTRODUCTION ................................................................................................................................................... 13 1.1 Overview ...................................................................................................................................................... 13 1.1.1 Compliance ............................................................................................................................................ 13 1.1.2 Types of Certificates .............................................................................................................................. 13 1.1.2.1 CA-Certificates .............................................................................................................................. 13 1.1.2.1.1 Missing Heading ........................................................................................................................ 14 1.1.2.1.2 Missing Heading ........................................................................................................................ 14 1.1.2.1.3 Terminus CA-Certificates .......................................................................................................... 14 1.1.2.1.4 Policy CA-Certificates ................................................................................................................ 14 1.1.2.1.5 Technically Constrained CA-Certificates ..................................................................................
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • A Practical Evaluation of a High-Security Energy-Efficient
    sensors Article A Practical Evaluation of a High-Security Energy-Efficient Gateway for IoT Fog Computing Applications Manuel Suárez-Albela * , Tiago M. Fernández-Caramés , Paula Fraga-Lamas and Luis Castedo Department Computer Engineering, Faculty of Computer Science, Universidade da Coruña, 15071 A Coruña, Spain; [email protected] (T.M.F.-C.); [email protected] (P.F.-L.); [email protected] (L.C.) * Correspondence: [email protected]; Tel.: +34-981-167-000 (ext. 6051) Received: 28 July 2017; Accepted: 19 August 2017; Published: 29 August 2017 Abstract: Fog computing extends cloud computing to the edge of a network enabling new Internet of Things (IoT) applications and services, which may involve critical data that require privacy and security. In an IoT fog computing system, three elements can be distinguished: IoT nodes that collect data, the cloud, and interconnected IoT gateways that exchange messages with the IoT nodes and with the cloud. This article focuses on securing IoT gateways, which are assumed to be constrained in terms of computational resources, but that are able to offload some processing from the cloud and to reduce the latency in the responses to the IoT nodes. However, it is usually taken for granted that IoT gateways have direct access to the electrical grid, which is not always the case: in mission-critical applications like natural disaster relief or environmental monitoring, it is common to deploy IoT nodes and gateways in large areas where electricity comes from solar or wind energy that charge the batteries that power every device. In this article, how to secure IoT gateway communications while minimizing power consumption is analyzed.
    [Show full text]
  • How to Build an X.509 PKI That Works
    How to build a PKI that works Peter Gutmann University of Auckland How to build an X.509 PKI that works Peter Gutmann University of Auckland Preliminaries Whose PKI are we talking about here? •Not SSL certs –Certificate manufacturing, not PKI It’s just an expensive way of doing authenticated DNS lookups with a TTL of one year. Plenty of PK, precious little I — Peter Gutmann on the crypto list •Not PGP, SPKI, *ML, etc –Doing fairly well in their (low-I) area •Not government PKI initiatives –Government IT project reality distortion field, keep pumping in money until it cries Uncle –Even then, the reality distortion has failed in parts of Europe, Australia Preliminaries (ctd) This is PKI for the rest of us •Businesses, individuals, etc Talk covers exclusively technical issues •Policies are someone else’s problem Ted says that whenever he gets asked a religious question he doesn’t understand he always responds with “Ah, that must be an ecumenical matter” which universally produces nods of admiration at the profound wisdom of the statement. It seems that that the PKIX list equivalent is “Ah, that must be a policy matter” — Father Ted (via Anon) •Some religion may sneak in Preliminaries (ctd) Microsoft bashing: An apology in advance •Their PKI software is the most widespread, and features prominently in examples because of this •There is no indication that other software is any better, it just gets less publicity It may be a little controversial… 56th IETF agenda item, submitted as a joke when someone pointed out that PKIX didn’t have any agenda What needs to be done to make PKI work? This forum will be open to all PKIX members, and will constitute a large pool filled knee-deep with custard.
    [Show full text]
  • Security Issues in the Diffie-Hellman Key Agreement Protocol
    Security Issues in the Diffie-Hellman Key Agreement Protocol Jean-Franc¸ois Raymond and Anton Stiglic Zero-Knowledge Systems Inc. jfr, anton ¡ @zeroknowledge.com Abstract Diffie-Hellman key agreement protocol [20] implementations have been plagued by serious security flaws. The attacks can be very subtle and, more often than not, have not been taken into account by protocol designers. In this summary we discuss both theoretical attacks against the Diffie-Hellman key agreement pro- tocol and attacks based on implementation details . It is hoped that computer se- curity practitioners will obtain enough information to build and design secure and efficient versions of this classic key agreement protocol. 1 Introduction In their landmark 1976 paper “New Directions in Cryptography”[20], Diffie and Hell- man present a secure key agreement protocol that can be carried out over public com- munication channels. Their protocol is still widely used to this day. Even though the protocol seems quite simple, it can be vulnerable to certain attacks. As with many cryptographic protocols, the Diffie-Hellman key agreement protocol (DH protocol) has subtle problems that cryptographers have taken many years to discover. This vulnerability is compounded by the fact that programmers often do not have a proper understanding of the security issues. In fact, bad implementations of crypto- graphic protocols are, unfortunately, common [2]. In this work, we attempt to give a comprehensive listing of attacks on the DH proto- col. This listing will, in turn, allow us to motivate protocol design decisions. Note that throughout this presentation emphasis is placed on practice. After reading this paper, one might not have an extremely detailed understanding of previous work and theoret- ical problems, but should have a very good idea about how to securely implement the DH protocol in different settings.
    [Show full text]
  • Security Policies for the Federal Public Key Infrastructure
    Security Policies for the Federal Public Key Infrastructure Noel A. Nazario Security Technology Group National Institute of Standards and Technology Abstract This document discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI). Federal PKI policies deal with the generation, deactivation, and dissemination of public key certificates, the integrity of the infrastructure, maintenance of records, identification of certificate holders, and the establishment of trust relationships between Certification Authorities (CAs). The verification of a digital signature is not sufficient indication of the trustworthiness of an electronic message or data file. The verifier needs to factor the trustworthiness of the CAs involved in the certification of the sender. To accomplish this, the verifier needs to examine the certificate policy for those CAs. The Federal PKI Technical Security Policy establishes guidelines for the operation of Federal CAs and the identification of the parties requesting certification. It also defines Policy Approving Authorities (PAA) responsible for assessing the policies and operational practices of all Federal CAs within a domain and assigning them corresponding Federal Assurance Levels. These assurance levels may be used in lieu of a certificate policy when making an on-line determination of the trustworthiness of a certificate. Key words Certificate policy, Federal Assurance Levels, PAA, PKI, Policy Approving Authority, public key infrastructure, security policy. SECURITY POLICIES FOR THE FEDERAL PUBLIC KEY INFRASTRUCTURE Noel A. Nazario NIST North, Room 426 820 West Diamond Avenue Gaithersburg, MD 20899 [email protected] Introduction and Background This paper discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI).
    [Show full text]