Page 2 :
CRYPTOGRAPHY AND, NETWORK SECURITY, , PRINCIPLES AND PRACTICE, SEVENTH EDITION, GLOBAL EDITION, , William Stallings, , Boston Columbus Indianapolis New York San Francisco Hoboken, Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto, Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo, , Hiva-Network.Com
Page 3 :
For Tricia: never dull, never boring,, the smartest and bravest person, I know, Vice President and Editorial Director, ECS:, Marcia J. Horton, Executive Editor: Tracy Johnson (Dunkelberger), Editorial Assistant: Kristy Alaura, Acquisitions Editor, Global Editions: Abhijit Baroi, Program Manager: Carole Snyder, Project Manager: Robert Engelhardt, Project Editor, Global Editions: K.K. Neelakantan, Media Team Lead: Steve Wright, R&P Manager: Rachel Youdelman, R&P Senior Project Manager: William Opaluch, Senior Operations Specialist: Maura Zaldivar-Garcia, Inventory Manager: Meredith Maresca, , Inventory Manager: Meredith Maresca, Senior Manufacturing Controller, Global Editions:, Trudy Kimber, Media Production Manager, Global Editions:, Vikram Kumar, Product Marketing Manager: Bram Van Kempen, Marketing Assistant: Jon Bryant, Cover Designer: Lumina Datamatics, Cover Art: © goghy73 / Shutterstock, Full-Service Project Management:, Chandrakala Prakash, SPi Global, Composition: SPi Global, , Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook, appear on page 753., Pearson Education Limited, Edinburgh Gate, Harlow, Essex CM20 2JE, England, and Associated Companies throughout the world, Visit us on the World Wide Web at:, www.pearsonglobaleditions.com, © Pearson Education Limited 2017, The right of William Stallings to be identified as the author of this work has been asserted by him in accordance, with the Copyright, Designs and Patents Act 1988., Authorized adaptation from the United States edition, entitled Cryptography and Network Security: Principles and, Practice, 7th Edition, ISBN 978-0-13-444428-4, by William Stallings published by Pearson Education © 2017., All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in, any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior, written permission of the publisher or a license permitting restricted copying in the United Kingdom issued by the, Copyright Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS., All trademarks used herein are the property of their respective owners. The use of any trademark in this text does, not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such, trademarks imply any affiliation with or endorsement of this book by such owners., British Library Cataloguing-in-Publication Data, A catalogue record for this book is available from the British Library, 10 9 8 7 6 5 4 3 2 1, ISBN 10:1-292-15858-1, ISBN 13: 978-1-292-15858-7, Typeset by SPi Global, Printed and bound in Malaysia.
Page 4 :
CONTENTS, Notation 10, Preface 12, About the Author 18, PART ONE: BACKGROUND 19, Chapter 1 Computer and Network Security Concepts 19, 1.1, Computer Security Concepts 21, 1.2, The OSI Security Architecture 26, 1.3, Security Attacks 27, 1.4, Security Services 29, 1.5, Security Mechanisms 32, 1.6, Fundamental Security Design Principles 34, 1.7, Attack Surfaces and Attack Trees 37, 1.8, A Model for Network Security 41, 1.9, Standards 43, 1.10, Key Terms, Review Questions, and Problems 44, Chapter 2 Introduction to Number Theory 46, 2.1, Divisibility and the Division Algorithm 47, 2.2, The Euclidean Algorithm 49, 2.3, Modular Arithmetic 53, 2.4, Prime Numbers 61, 2.5, Fermat’s and Euler’s Theorems 64, 2.6, Testing for Primality 68, 2.7, The Chinese Remainder Theorem 71, 2.8, Discrete Logarithms 73, 2.9, Key Terms, Review Questions, and Problems 78, Appendix 2A The Meaning of Mod 82, PART TWO: SYMMETRIC CIPHERS 85, Chapter 3 Classical Encryption Techniques 85, 3.1, Symmetric Cipher Model 86, 3.2, Substitution Techniques 92, 3.3, Transposition Techniques 107, 3.4, Rotor Machines 108, 3.5, Steganography 110, 3.6, Key Terms, Review Questions, and Problems 112, Chapter 4 Block Ciphers and the Data Encryption Standard 118, 4.1, Traditional Block Cipher Structure 119, 4.2, The Data Encryption Standard 129, 4.3, A DES Example 131, 4.4, The Strength of DES 134, , 3
Page 5 :
4, , CONTENTS, , 4.5, Block Cipher Design Principles 135, 4.6, Key Terms, Review Questions, and Problems 137, Chapter 5 Finite Fields 141, 5.1, Groups 143, 5.2, Rings 145, 5.3, Fields 146, 5.4, Finite Fields of the Form GF(p) 147, 5.5, Polynomial Arithmetic 151, 5.6, Finite Fields of the Form GF(2n) 157, 5.7, Key Terms, Review Questions, and Problems 169, Chapter 6 Advanced Encryption Standard 171, 6.1, Finite Field Arithmetic 172, 6.2, AES Structure 174, 6.3, AES Transformation Functions 179, 6.4, AES Key Expansion 190, 6.5, An AES Example 193, 6.6, AES Implementation 197, 6.7, Key Terms, Review Questions, and Problems 202, Appendix 6A Polynomials with Coefficients in GF(28) 203, Chapter 7 Block Cipher Operation 207, 7.1, Multiple Encryption and Triple DES 208, 7.2, Electronic Codebook 213, 7.3, Cipher Block Chaining Mode 216, 7.4, Cipher Feedback Mode 218, 7.5, Output Feedback Mode 220, 7.6, Counter Mode 222, 7.7, XTS-AES Mode for Block-Oriented Storage Devices 224, 7.8, Format-Preserving Encryption 231, 7.9, Key Terms, Review Questions, and Problems 245, Chapter 8 Random Bit Generation and Stream Ciphers 250, 8.1, Principles of Pseudorandom Number Generation 252, 8.2, Pseudorandom Number Generators 258, 8.3, Pseudorandom Number Generation Using a Block Cipher 261, 8.4, Stream Ciphers 267, 8.5, RC4 269, 8.6, True Random Number Generators 271, 8.7, Key Terms, Review Questions, and Problems 280, PART THREE: ASYMMETRIC CIPHERS 283, Chapter 9 Public-Key Cryptography and RSA 283, 9.1, Principles of Public-Key Cryptosystems 285, 9.2, The RSA Algorithm 294, 9.3, Key Terms, Review Questions, and Problems 308
Page 6 :
CONTENTS, , Chapter 10 Other Public-Key Cryptosystems 313, 10.1, Diffie-Hellman Key Exchange 314, 10.2, Elgamal Cryptographic System 318, 10.3, Elliptic Curve Arithmetic 321, 10.4, Elliptic Curve Cryptography 330, 10.5, Pseudorandom Number Generation Based on an Asymmetric Cipher 334, 10.6, Key Terms, Review Questions, and Problems 336, PART FOUR: CRYPTOGRAPHIC DATA INTEGRITY ALGORITHMS 339, Chapter 11 Cryptographic Hash Functions 339, 11.1, Applications of Cryptographic Hash Functions 341, 11.2, Two Simple Hash Functions 346, 11.3, Requirements and Security 348, 11.4, Hash Functions Based on Cipher Block Chaining 354, 11.5, Secure Hash Algorithm (SHA) 355, 11.6, SHA-3 365, 11.7, Key Terms, Review Questions, and Problems 377, Chapter 12 Message Authentication Codes 381, 12.1, Message Authentication Requirements 382, 12.2, Message Authentication Functions 383, 12.3, Requirements for Message Authentication Codes 391, 12.4, Security of MACs 393, 12.5, MACs Based on Hash Functions: HMAC 394, 12.6, MACs Based on Block Ciphers: DAA and CMAC 399, 12.7, Authenticated Encryption: CCM and GCM 402, 12.8, Key Wrapping 408, 12.9, Pseudorandom Number Generation Using Hash Functions and MACs 413, 12.10, Key Terms, Review Questions, and Problems 416, Chapter 13 Digital Signatures 419, 13.1, Digital Signatures 421, 13.2, Elgamal Digital Signature Scheme 424, 13.3, Schnorr Digital Signature Scheme 425, 13.4, NIST Digital Signature Algorithm 426, 13.5, Elliptic Curve Digital Signature Algorithm 430, 13.6, RSA-PSS Digital Signature Algorithm 433, 13.7, Key Terms, Review Questions, and Problems 438, PART FIVE: MUTUAL TRUST 441, Chapter 14 Key Management and Distribution 441, 14.1, Symmetric Key Distribution Using Symmetric Encryption 442, 14.2, Symmetric Key Distribution Using Asymmetric Encryption 451, Distribution of Public Keys 454, 14.3, 14.4, X.509 Certificates 459, , 5
Page 7 :
6, , CONTENTS, , 14.5, Public-Key Infrastructure 467, 14.6, Key Terms, Review Questions, and Problems 469, Chapter 15 User Authentication 473, 15.1, Remote User-Authentication Principles 474, 15.2, Remote User-Authentication Using Symmetric Encryption 478, 15.3, Kerberos 482, 15.4, Remote User-Authentication Using Asymmetric Encryption 500, 15.5, Federated Identity Management 502, 15.6, Personal Identity Verification 508, 15.7, Key Terms, Review Questions, and Problems 515, PART SIX: NETWORK AND INTERNET SECURITY 519, Chapter 16 Network Access Control and Cloud Security 519, 16.1, Network Access Control 520, 16.2, Extensible Authentication Protocol 523, 16.3, IEEE 802.1X Port-Based Network Access Control 527, 16.4, Cloud Computing 529, 16.5, Cloud Security Risks and Countermeasures 535, 16.6, Data Protection in the Cloud 537, 16.7, Cloud Security as a Service 541, 16.8, Addressing Cloud Computing Security Concerns 544, 16.9, Key Terms, Review Questions, and Problems 545, Chapter 17 Transport-Level Security 546, 17.1, Web Security Considerations 547, 17.2, Transport Layer Security 549, 17.3, HTTPS 566, 17.4, Secure Shell (SSH) 567, 17.5, Key Terms, Review Questions, and Problems 579, Chapter 18 Wireless Network Security 581, 18.1, Wireless Security 582, 18.2, Mobile Device Security 585, 18.3, IEEE 802.11 Wireless LAN Overview 589, 18.4, IEEE 802.11i Wireless LAN Security 595, 18.5, Key Terms, Review Questions, and Problems 610, Chapter 19 Electronic Mail Security 612, 19.1, Internet Mail Architecture 613, 19.2, Email Formats 617, 19.3, Email Threats and Comprehensive Email Security 625, 19.4, S/MIME 627, 19.5, Pretty Good Privacy 638, 19.6, DNSSEC 639, 19.7, DNS-Based Authentication of Named Entities 643, 19.8, Sender Policy Framework 645, 19.9, DomainKeys Identified Mail 648
Page 8 :
CONTENTS, , 19.10, 19.11, Chapter 20, 20.1, 20.2, 20.3, 20.4, 20.5, 20.6, 20.7, , Domain-Based Message Authentication, Reporting, and Conformance 654, Key Terms, Review Questions, and Problems 659, IP Security 661, IP Security Overview 662, IP Security Policy 668, Encapsulating Security Payload 673, Combining Security Associations 681, Internet Key Exchange 684, Cryptographic Suites 692, Key Terms, Review Questions, and Problems 694, , APPENDICES 696, Appendix A Projects for Teaching Cryptography and Network Security 696, A.1, Sage Computer Algebra Projects 697, A.2, Hacking Project 698, A.3, Block Cipher Projects 699, A.4, Laboratory Exercises 699, A.5, Research Projects 699, A.6, Programming Projects 700, A.7, Practical Security Assessments 700, A.8, Firewall Projects 701, A.9, Case Studies 701, A.10, Writing Assignments 701, A.11, Reading/Report Assignments 702, A.12, Discussion Topics 702, Appendix B Sage Examples 703, B.1, B.2, B.3, B.4, B.5, B.6, B.7, B.8, B.9, B.10, B.11, References, Credits 753, Index 754, , Linear Algebra and Matrix Functionality 704, Chapter 2: Number Theory 705, Chapter 3: Classical Encryption 710, Chapter 4: Block Ciphers and the Data Encryption Standard 713, Chapter 5: Basic Concepts in Number Theory and Finite Fields 717, Chapter 6: Advanced Encryption Standard 724, Chapter 8: Pseudorandom Number Generation and Stream Ciphers 729, Chapter 9: Public-Key Cryptography and RSA 731, Chapter 10: Other Public-Key Cryptosystems 734, Chapter 11: Cryptographic Hash Functions 739, Chapter 13: Digital Signatures 741, 744, , 7
Page 9 :
8, , CONTENTS, , ONLINE CHAPTERS AND APPENDICES1, PART SEVEN: SYSTEM SECURITY, Chapter 21 Malicious Software, 21.1, Types of Malicious Software (Malware), 21.2, Advanced Persistent Threat, 21.3, Propagation—Infected Content—Viruses, 21.4, Propagation—Vulnerability Exploit—Worms, 21.5, Propagation—Social Engineering—Spam E-mail, Trojans, 21.6, Payload—System Corruption, 21.7, Payload—Attack Agent—Zombie, Bots, 21.8, Payload—Information Theft—Keyloggers, Phishing, Spyware, 21.9, Payload—Stealthing—Backdoors, Rootkits, 21.10, Countermeasures, 21.11, Distributed Denial of Service Attacks, 21.12, References, 21.13, Key Terms, Review Questions, and Problems, Chapter 22 Intruders, 22.1, Intruders, 22.2, Intrusion Detection, 22.3, Password Management, 22.4, References, 22.5, Key Terms, Review Questions, and Problems, Chapter 23 Firewalls, 23.1, The Need for Firewalls, 23.2, Firewall Characteristics and Access Policy, 23.3, Types of Firewalls, 23.4, Firewall Basing, 23.5, Firewall Location and Configurations, 23.6, References, 23.7, Key Terms, Review Questions, and Problems, PART EIGHT: LEGAL AND ETHICAL ISSUES, Chapter 24 Legal and Ethical Aspects, 24.1, Cybercrime and Computer Crime, 24.2, Intellectual Property, 24.3, Privacy, 24.4, Ethical Issues, 24.5, Recommended Reading, 24.6, References, 24.7, Key Terms, Review Questions, and Problems, 24.A, Information Privacy, 1, , Online chapters, appendices, and other documents are at the Companion Website, available via the, access card at the front of this book.
Page 10 :
CONTENTS, , Appendix C, , Sage Exercises, , Appendix D, , Standards and Standard-Setting Organizations, , Appendix E, , Basic Concepts from Linear Algebra, , Appendix F, , Measures of Secrecy and Security, , Appendix G, , Simplified DES, , Appendix H, , Evaluation Criteria for AES, , Appendix I, , Simplified AES, , Appendix J, , The Knapsack Algorithm, , Appendix K, , Proof of the Digital Signature Algorithm, , Appendix L, , TCP/IP and OSI, , Appendix M, , Java Cryptographic APIs, , Appendix N, , MD5 Hash Function, , Appendix O, , Data Compression Using ZIP, , Appendix P, , PGP, , Appendix Q, , The International Reference Alphabet, , Appendix R, , Proof of the RSA Algorithm, , Appendix S, , Data Encryption Standard, , Appendix T, , Kerberos Encryption Techniques, , Appendix U, , Mathematical Basis of the Birthday Attack, , Appendix V, , Evaluation Criteria for SHA-3, , Appendix W, , The Complexity of Algorithms, , Appendix X, , Radix-64 Conversion, , Appendix Y, , The Base Rate Fallacy, , Glossary, , 9
Page 11 :
NOTATION, Symbol, , Expression, , Meaning, , D, K, , D(K, Y), , Symmetric decryption of ciphertext Y using secret key K, , D, PRa, , D(PRa, Y), , Asymmetric decryption of ciphertext Y using A’s private key PRa, , D, PUa, , D(PUa, Y), , Asymmetric decryption of ciphertext Y using A’s public key PUa, , E, K, , E(K, X), , Symmetric encryption of plaintext X using secret key K, , E, PRa, , E(PRa, X), , Asymmetric encryption of plaintext X using A’s private key PRa, , E, PUa, , E(PUa, X), , Asymmetric encryption of plaintext X using A’s public key PUa, , K, , Secret key, , PRa, , Private key of user A, , PUa, , Public key of user A, , MAC, K, , MAC(K, X), , Message authentication code of message X using secret key K, , GF(p), , The finite field of order p, where p is prime.The field is defined as, the set Zp together with the arithmetic operations modulo p., , GF(2n), , The finite field of order 2n, , Zn, , Set of nonnegative integers less than n, , gcd, , gcd(i, j), , Greatest common divisor; the largest positive integer that, divides both i and j with no remainder on division., , mod, , a mod m, , Remainder after division of a by m, , mod, K, , a K b (mod m), , a mod m = b mod m, , mod, [, , a [ b (mod m), , a mod m ≠ b mod m, , dlog, , dlog a,p(b), , Discrete logarithm of the number b for the base a (mod p), , w, , f(n), , The number of positive integers less than n and relatively, prime to n., This is Euler’s totient function., , Σ, Π, , n, , a ai, , a1 + a2 + g + an, , i=1, n, , q ai, , a1 * a2 * g * an, , i=1, , , , i j, , i divides j, which means that there is no remainder when j is, divided by i, , , , , a, , Absolute value of a, , 10, Hiva-Network.Com
Page 12 :
NOTATION, Symbol, , Expression, , Meaning, , }, , x}y, , x concatenated with y, , ≈, , x ≈ y, , x is approximately equal to y, , ⊕, , x⊕y, , Exclusive-OR of x and y for single-bit variables;, Bitwise exclusive-OR of x and y for multiple-bit variables, , :, ;, , :x ;, , The largest integer less than or equal to x, , ∈, , x∈S, , The element x is contained in the set S., , ·, , A · (a1, a2,, c ak), , The integer A corresponds to the sequence of integers, (a1, a2, c ak), , 11
Page 13 :
PREFACE, WHAT’S NEW IN THE SEVENTH EDITION, In the four years since the sixth edition of this book was published, the field has seen continued innovations and improvements. In this new edition, I try to capture these changes while, maintaining a broad and comprehensive coverage of the entire field. To begin this process of, revision, the sixth edition of this book was extensively reviewed by a number of professors, who teach the subject and by professionals working in the field. The result is that, in many, places, the narrative has been clarified and tightened, and illustrations have been improved., Beyond these refinements to improve pedagogy and user-friendliness, there have been, substantive changes throughout the book. Roughly the same chapter organization has been, retained, but much of the material has been revised and new material has been added. The, most noteworthy changes are as follows:, ■, , Fundamental security design principles: Chapter 1 includes a new section discussing the, security design principles listed as fundamental by the National Centers of Academic, Excellence in Information Assurance/Cyber Defense, which is jointly sponsored by the, U.S. National Security Agency and the U.S. Department of Homeland Security., , ■, , Attack surfaces and attack trees: Chapter 1 includes a new section describing these two, concepts, which are useful in evaluating and classifying security threats., Number theory coverage: The material on number theory has been consolidated, into a single chapter, Chapter 2. This makes for a convenient reference. The relevant, portions of Chapter 2 can be assigned as needed., Finite fields: The chapter on finite fields has been revised and expanded with additional text and new figures to enhance understanding., Format-preserving encryption: This relatively new mode of encryption is enjoying, increasing commercial success. A new section in Chapter 7 covers this method., Conditioning and health testing for true random number generators: Chapter 8 now, provides coverage of these important topics., User authentication model: Chapter 15 includes a new description of a general model, for user authentication, which helps to unify the discussion of the various approaches, to user authentication., Cloud security: The material on cloud security in Chapter 16 has been updated and, expanded to reflect its importance and recent developments., Transport Layer Security (TLS): The treatment of TLS in Chapter 17 has been updated,, reorganized to improve clarity, and now includes a discussion of the new TLS version 1.3., Email Security: Chapter 19 has been completely rewritten to provide a comprehensive, and up-to-date discussion of email security. It includes:, — New: discussion of email threats and a comprehensive approach to email security., — New: discussion of STARTTLS, which provides confidentiality and authentication, for SMTP., , ■, , ■, ■, ■, ■, , ■, ■, ■, , 12
Page 14 :
PREFACE, , 13, , — Revised: treatment of S/MIME has been updated to reflect the latest version 3.2., — New: discussion of DNSSEC and its role in supporting email security., — New: discussion of DNS-based Authentication of Named Entities (DANE) and the, use of this approach to enhance security for certificate use in SMTP and S/MIME., — New: discussion of Sender Policy Framework (SPF), which is the standardized way, for a sending domain to identify and assert the mail senders for a given domain., — Revised: discussion of DomainKeys Identified Mail (DKIM) has been revised., — New: discussion of Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows email senders to specify policy on how their mail should, be handled, the types of reports that receivers can send back, and the frequency, those reports should be sent., , OBJECTIVES, It is the purpose of this book to provide a practical survey of both the principles and practice, of cryptography and network security. In the first part of the book, the basic issues to be, addressed by a network security capability are explored by providing a tutorial and survey, of cryptography and network security technology. The latter part of the book deals with the, practice of network security: practical applications that have been implemented and are in, use to provide network security., The subject, and therefore this book, draws on a variety of disciplines. In particular,, it is impossible to appreciate the significance of some of the techniques discussed in this, book without a basic understanding of number theory and some results from probability, theory. Nevertheless, an attempt has been made to make the book self-contained. The book, not only presents the basic mathematical results that are needed but provides the reader, with an intuitive understanding of those results. Such background material is introduced, as needed. This approach helps to motivate the material that is introduced, and the author, considers this preferable to simply presenting all of the mathematical material in a lump at, the beginning of the book., , SUPPORT OF ACM/IEEE COMPUTER SCIENCE CURRICULA 2013, The book is intended for both academic and professional audiences. As a textbook, it is, intended as a one-semester undergraduate course in cryptography and network security for, computer science, computer engineering, and electrical engineering majors. The changes to, this edition are intended to provide support of the ACM/IEEE Computer Science Curricula, 2013 (CS2013). CS2013 adds Information Assurance and Security (IAS) to the curriculum recommendation as one of the Knowledge Areas in the Computer Science Body of Knowledge., The document states that IAS is now part of the curriculum recommendation because of the, critical role of IAS in computer science education. CS2013 divides all course work into three, categories: Core-Tier 1 (all topics should be included in the curriculum), Core-Tier-2 (all or, almost all topics should be included), and elective (desirable to provide breadth and depth)., In the IAS area, CS2013 recommends topics in Fundamental Concepts and Network Security
Page 15 :
14, , PREFACE, , in Tier 1 and Tier 2, and Cryptography topics as elective. This text covers virtually all of the, topics listed by CS2013 in these three categories., The book also serves as a basic reference volume and is suitable for self-study., , PLAN OF THE TEXT, The book is divided into eight parts., ■, ■, ■, ■, ■, ■, ■, ■, , Background, Symmetric Ciphers, Asymmetric Ciphers, Cryptographic Data Integrity Algorithms, Mutual Trust, Network and Internet Security, System Security, Legal and Ethical Issues, , The book includes a number of pedagogic features, including the use of the computer, algebra system Sage and numerous figures and tables to clarify the discussions. Each chapter includes a list of key words, review questions, homework problems, and suggestions, for further reading. The book also includes an extensive glossary, a list of frequently used, acronyms, and a bibliography. In addition, a test bank is available to instructors., , INSTRUCTOR SUPPORT MATERIALS, The major goal of this text is to make it as effective a teaching tool for this exciting and, fast-moving subject as possible. This goal is reflected both in the structure of the book and in, the supporting material. The text is accompanied by the following supplementary material, that will aid the instructor:, ■, , Solutions manual: Solutions to all end-of-chapter Review Questions and Problems., , ■, , Projects manual: Suggested project assignments for all of the project categories listed, below., PowerPoint slides: A set of slides covering all chapters, suitable for use in lecturing., PDF files: Reproductions of all figures and tables from the book., Test bank: A chapter-by-chapter set of questions with a separate file of answers., , ■, ■, ■, ■, , Sample syllabuses: The text contains more material than can be conveniently covered, in one semester. Accordingly, instructors are provided with several sample syllabuses, that guide the use of the text within limited time., , All of these support materials are available at the Instructor Resource Center, (IRC) for this textbook, which can be reached through the publisher’s Web site, www.pearsonglobaleditions.com/stallings. To gain access to the IRC, please contact your, local Pearson sales representative.
Page 16 :
PREFACE, , 15, , PROJECTS AND OTHER STUDENT EXERCISES, For many instructors, an important component of a cryptography or network security course, is a project or set of projects by which the student gets hands-on experience to reinforce, concepts from the text. This book provides an unparalleled degree of support, including a, projects component in the course. The IRC not only includes guidance on how to assign and, structure the projects, but also includes a set of project assignments that covers a broad range, of topics from the text:, ■, , Sage projects: Described in the next section., , ■, , Hacking project: Exercise designed to illuminate the key issues in intrusion detection, and prevention., Block cipher projects: A lab that explores the operation of the AES encryption algorithm by tracing its execution, computing one round by hand, and then exploring the, various block cipher modes of use. The lab also covers DES. In both cases, an online, Java applet is used (or can be downloaded) to execute AES or DES., Lab exercises: A series of projects that involve programming and experimenting with, concepts from the book., Research projects: A series of research assignments that instruct the student to research, a particular topic on the Internet and write a report., Programming projects: A series of programming projects that cover a broad range of, topics and that can be implemented in any suitable language on any platform., Practical security assessments: A set of exercises to examine current infrastructure and, practices of an existing organization., Firewall projects: A portable network firewall visualization simulator, together with, exercises for teaching the fundamentals of firewalls., Case studies: A set of real-world case studies, including learning objectives, case, description, and a series of case discussion questions., Writing assignments: A set of suggested writing assignments, organized by chapter., Reading/report assignments: A list of papers in the literature—one for each chapter—, that can be assigned for the student to read and then write a short report., , ■, , ■, ■, ■, ■, ■, ■, ■, ■, , This diverse set of projects and other student exercises enables the instructor to use, the book as one component in a rich and varied learning experience and to tailor a course, plan to meet the specific needs of the instructor and students. See Appendix A in this book, for details., , THE SAGE COMPUTER ALGEBRA SYSTEM, One of the most important features of this book is the use of Sage for cryptographic examples, and homework assignments. Sage is an open-source, multiplatform, freeware package that, implements a very powerful, flexible, and easily learned mathematics and computer algebra, system. Unlike competing systems (such as Mathematica, Maple, and MATLAB), there are
Page 17 :
16, , PREFACE, , no licensing agreements or fees involved. Thus, Sage can be made available on computers, and networks at school, and students can individually download the software to their own, personal computers for use at home. Another advantage of using Sage is that students learn, a powerful, flexible tool that can be used for virtually any mathematical application, not, just cryptography., The use of Sage can make a significant difference to the teaching of the mathematics, of cryptographic algorithms. This book provides a large number of examples of the use of, Sage covering many cryptographic concepts in Appendix B, which is included in this book., Appendix C lists exercises in each of these topic areas to enable the student to gain, hands-on experience with cryptographic algorithms. This appendix is available to instructors at the IRC for this book. Appendix C includes a section on how to download and get, started with Sage, a section on programming with Sage, and exercises that can be assigned to, students in the following categories:, ■, , Chapter 2—Number Theory and Finite Fields: Euclidean and extended Euclidean, algorithms, polynomial arithmetic, GF(24), Euler’s Totient function, Miller–Rabin, factoring, modular exponentiation, discrete logarithm, and Chinese remainder theorem., , ■, , Chapter 3—Classical Encryption: Affine ciphers and the Hill cipher., Chapter 4—Block Ciphers and the Data Encryption Standard: Exercises based, on SDES., Chapter 6—Advanced Encryption Standard: Exercises based on SAES., Chapter 8—Pseudorandom Number Generation and Stream Ciphers: Blum Blum, Shub, linear congruential generator, and ANSI X9.17 PRNG., Chapter 9—Public-Key Cryptography and RSA: RSA encrypt/decrypt and signing., Chapter 10—Other Public-Key Cryptosystems: Diffie–Hellman, elliptic curve., Chapter 11—Cryptographic Hash Functions: Number-theoretic hash function., Chapter 13—Digital Signatures: DSA., , ■, ■, ■, ■, ■, ■, ■, , ONLINE DOCUMENTS FOR STUDENTS, For this new edition, a tremendous amount of original supporting material for students has, been made available online., Purchasing this textbook new also grants the reader six months of access to the, Companion Website, which includes the following materials:, ■, , Online chapters: To limit the size and cost of the book, four chapters of the book are, provided in PDF format. This includes three chapters on computer security and one on, legal and ethical issues. The chapters are listed in this book’s table of contents., , ■, , Online appendices: There are numerous interesting topics that support material found, in the text but whose inclusion is not warranted in the printed text. A total of 20 online, appendices cover these topics for the interested student. The appendices are listed in, this book’s table of contents.
Page 18 :
PREFACE, ■, ■, ■, ■, , 17, , Homework problems and solutions: To aid the student in understanding the material,, a separate set of homework problems with solutions are available., Key papers: A number of papers from the professional literature, many hard to find,, are provided for further reading., Supporting documents: A variety of other useful documents are referenced in the text, and provided online., Sage code: The Sage code from the examples in Appendix B is useful in case the student, wants to play around with the examples., , To access the Companion Website, follow the instructions for “digital resources for, students” found in the front of this book., , ACKNOWLEDGMENTS, This new edition has benefited from review by a number of people who gave generously, of their time and expertise. The following professors reviewed all or a large part of the, manuscript: Hossein Beyzavi (Marymount University), Donald F. Costello (University of, Nebraska–Lincoln), James Haralambides (Barry University), Anand Seetharam (California, State University at Monterey Bay), Marius C. Silaghi (Florida Institute of Technology),, Shambhu Upadhyaya (University at Buffalo), Zhengping Wu (California State University, at San Bernardino), Liangliang Xiao (Frostburg State University), Seong-Moo (Sam) Yoo, (The University of Alabama in Huntsville), and Hong Zhang (Armstrong State University)., Thanks also to the people who provided detailed technical reviews of one or more, chapters: Dino M. Amaral, Chris Andrew, Prof. (Dr). C. Annamalai, Andrew Bain, Riccardo, Bernardini, Olivier Blazy, Zervopoulou Christina, Maria Christofi, Dhananjoy Dey, Mario, Emmanuel, Mike Fikuart, Alexander Fries, Pierpaolo Giacomin, Pedro R. M. Inácio,, Daniela Tamy Iwassa, Krzysztof Janowski, Sergey Katsev, Adnan Kilic, Rob Knox, Mina, Pourdashty, Yuri Poeluev, Pritesh Prajapati, Venkatesh Ramamoorthy, Andrea Razzini,, Rami Rosen, Javier Scodelaro, Jamshid Shokrollahi, Oscar So, and David Tillemans., In addition, I was fortunate to have reviews of individual topics by “subject-area, gurus,” including Jesse Walker of Intel (Intel’s Digital Random Number Generator), Russ, Housley of Vigil Security (key wrapping), Joan Daemen (AES), Edward F. Schaefer of, Santa Clara University (Simplified AES), Tim Mathews, formerly of RSA Laboratories, (S/MIME), Alfred Menezes of the University of Waterloo (elliptic curve cryptography),, William Sutton, Editor/Publisher of The Cryptogram (classical encryption), Avi Rubin of, Johns Hopkins University (number theory), Michael Markowitz of Information Security, Corporation (SHA and DSS), Don Davis of IBM Internet Security Systems (Kerberos),, Steve Kent of BBN Technologies (X.509), and Phil Zimmerman (PGP)., Nikhil Bhargava (IIT Delhi) developed the set of online homework problems and, solutions. Dan Shumow of Microsoft and the University of Washington developed all of, the Sage examples and assignments in Appendices B and C. Professor Sreekanth Malladi of, Dakota State University developed the hacking exercises. Lawrie Brown of the Australian, Defence Force Academy provided the AES/DES block cipher projects and the security, assessment assignments.
Page 19 :
18, , PREFACE, , Sanjay Rao and Ruben Torres of Purdue University developed the laboratory exercises, that appear in the IRC. The following people contributed project assignments that appear in, the instructor’s supplement: Henning Schulzrinne (Columbia University); Cetin Kaya Koc, (Oregon State University); and David Balenson (Trusted Information Systems and George, Washington University). Kim McLaughlin developed the test bank., Finally, I thank the many people responsible for the publication of this book, all of, whom did their usual excellent job. This includes the staff at Pearson, particularly my editor, Tracy Johnson, program manager Carole Snyder, and production manager Bob Engelhardt., Thanks also to the marketing and sales staffs at Pearson, without whose efforts this book, would not be in front of you., , ACKNOWLEDGMENTS FOR THE GLOBAL EDITION, Pearson would like to thank and acknowledge Somitra Kumar Sanadhya (Indraprastha, Institute of Information Technology Delhi), and Somanath Tripathy (Indian Institute of, Technology Patna) for contributing to the Global Edition, and Anwitaman Datta (Nanyang, Technological University Singapore), Atul Kahate (Pune University), Goutam Paul (Indian, Statistical Institute Kolkata), and Khyat Sharma for reviewing the Global Edition., , ABOUT THE AUTHOR, Dr. William Stallings has authored 18 titles, and counting revised editions, over 40 books, on computer security, computer networking, and computer architecture. His writings have, appeared in numerous publications, including the Proceedings of the IEEE, ACM Computing, Reviews, and Cryptologia., He has 13 times received the award for the best Computer Science textbook of the, year from the Text and Academic Authors Association., In over 30 years in the field, he has been a technical contributor, technical manager,, and an executive with several high-technology firms. He has designed and implemented, both TCP/IP-based and OSI-based protocol suites on a variety of computers and operating, systems, ranging from microcomputers to mainframes. As a consultant, he has advised government agencies, computer and software vendors, and major users on the design, selection,, and use of networking software and products., He created and maintains the Computer Science Student Resource Site at, ComputerScienceStudent.com. This site provides documents and links on a variety of, subjects of general interest to computer science students (and professionals). He is a member, of the editorial board of Cryptologia, a scholarly journal devoted to all aspects of cryptology., Dr. Stallings holds a PhD from MIT in computer science and a BS from Notre Dame, in electrical engineering.
Page 20 :
PART ONE: BACKGROUND, CHAPTER, , Computer and Network, Security Concepts, 1.1, , Computer Security Concepts, A Definition of Computer Security, Examples, The Challenges of Computer Security, , 1.2, , The OSI Security Architecture, , 1.3, , Security Attacks, Passive Attacks, Active Attacks, , 1.4, , Security Services, Authentication, Access Control, Data Confidentiality, Data Integrity, Nonrepudiation, Availability Service, , 1.5, , Security Mechanisms, , 1.6, , Fundamental Security Design Principles, , 1.7, , Attack Surfaces and Attack Trees, Attack Surfaces, Attack Trees, , 1.8, , A Model for Network Security, , 1.9, , Standards, , 1.10 Key Terms, Review Questions, and Problems, , 19, Hiva-Network.Com
Page 21 :
20, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Describe the key security requirements of confidentiality, integrity, and, availability., ◆ Describe the X.800 security architecture for OSI., ◆ Discuss the types of security threats and attacks that must be dealt with, and give examples of the types of threats and attacks that apply to different categories of computer and network assets., ◆ Explain the fundamental security design principles., ◆ Discuss the use of attack surfaces and attack trees., ◆ List and briefly describe key organizations involved in cryptography, standards., , This book focuses on two broad areas: cryptographic algorithms and protocols, which, have a broad range of applications; and network and Internet security, which rely, heavily on cryptographic techniques., Cryptographic algorithms and protocols can be grouped into four main areas:, ■, ■, ■, ■, , Symmetric encryption: Used to conceal the contents of blocks or streams of, data of any size, including messages, files, encryption keys, and passwords., Asymmetric encryption: Used to conceal small blocks of data, such as encryption keys and hash function values, which are used in digital signatures., Data integrity algorithms: Used to protect blocks of data, such as messages,, from alteration., Authentication protocols: These are schemes based on the use of cryptographic algorithms designed to authenticate the identity of entities., , The field of network and Internet security consists of measures to deter, prevent,, detect, and correct security violations that involve the transmission of information., That is a broad statement that covers a host of possibilities. To give you a feel for the, areas covered in this book, consider the following examples of security violations:, 1. User A transmits a file to user B. The file contains sensitive information, (e.g., payroll records) that is to be protected from disclosure. User C, who is, not authorized to read the file, is able to monitor the transmission and capture, a copy of the file during its transmission., 2. A network manager, D, transmits a message to a computer, E, under its management. The message instructs computer E to update an authorization file to, include the identities of a number of new users who are to be given access to, that computer. User F intercepts the message, alters its contents to add or delete, entries, and then forwards the message to computer E, which accepts the message as coming from manager D and updates its authorization file accordingly.
Page 22 :
1.1 / COMPUTER SECURITY CONCEPTS, , 21, , 3. Rather than intercept a message, user F constructs its own message with the, desired entries and transmits that message to computer E as if it had come, from manager D. Computer E accepts the message as coming from manager D, and updates its authorization file accordingly., 4. An employee is fired without warning. The personnel manager sends a message to a server system to invalidate the employee’s account. When the invalidation is accomplished, the server is to post a notice to the employee’s file as, confirmation of the action. The employee is able to intercept the message and, delay it long enough to make a final access to the server to retrieve sensitive, information. The message is then forwarded, the action taken, and the confirmation posted. The employee’s action may go unnoticed for some considerable time., 5. A message is sent from a customer to a stockbroker with instructions for various transactions. Subsequently, the investments lose value and the customer, denies sending the message., Although this list by no means exhausts the possible types of network security violations, it illustrates the range of concerns of network security., , 1.1 COMPUTER SECURITY CONCEPTS, A Definition of Computer Security, The NIST Computer Security Handbook [NIST95] defines the term computer security as follows:, Computer Security: The protection afforded to an automated information system, in order to attain the applicable objectives of preserving the integrity, availability,, and confidentiality of information system resources (includes hardware, software,, firmware, information/data, and telecommunications)., This definition introduces three key objectives that are at the heart of computer security:, ■, , Confidentiality: This term covers two related concepts:, Data1 confidentiality: Assures that private or confidential information is, not made available or disclosed to unauthorized individuals., Privacy: Assures that individuals control or influence what information related to them may be collected and stored and by whom and to whom that, information may be disclosed., , 1, , RFC 4949 defines information as “facts and ideas, which can be represented (encoded) as various forms, of data,” and data as “information in a specific physical representation, usually a sequence of symbols, that have meaning; especially a representation of information that can be processed or produced by a, computer.” Security literature typically does not make much of a distinction, nor does this book.
Page 23 :
CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, ■, , Integrity: This term covers two related concepts:, Data integrity: Assures that information (both stored and in transmitted packets) and programs are changed only in a specified and authorized, manner., System integrity: Assures that a system performs its intended function in, an unimpaired manner, free from deliberate or inadvertent unauthorized, manipulation of the system., , ■, , Availability: Assures that systems work promptly and service is not denied to, authorized users., , These three concepts form what is often referred to as the CIA triad. The, three concepts embody the fundamental security objectives for both data and for, information and computing services. For example, the NIST standard FIPS 199, (Standards for Security Categorization of Federal Information and Information, Systems) lists confidentiality, integrity, and availability as the three security objectives for information and for information systems. FIPS 199 provides a useful characterization of these three objectives in terms of requirements and the definition of, a loss of security in each category:, ■, , ■, , ■, , Confidentiality: Preserving authorized restrictions on information access, and disclosure, including means for protecting personal privacy and proprietary information. A loss of confidentiality is the unauthorized disclosure of, information., Integrity: Guarding against improper information modification or destruction, including ensuring information nonrepudiation and authenticity. A loss, of integrity is the unauthorized modification or destruction of information., Availability: Ensuring timely and reliable access to and use of information., A loss of availability is the disruption of access to or use of information or an, information system., , Although the use of the CIA triad to define security objectives is well established, some in the security field feel that additional concepts are needed to present a, complete picture (Figure 1.1). Two of the most commonly mentioned are as follows:, , y, , lit, , ility, , b, unta, , Acco, , Data, and, services, , In, , teg, , rit, , y, , ty, , nfi, , Co, , ntici, , tia, , n, de, , Auth, e, , 22, , Availability, , Figure 1.1, , Essential Network and Computer Security, Requirements
Page 24 :
1.1 / COMPUTER SECURITY CONCEPTS, ■, , ■, , 23, , Authenticity: The property of being genuine and being able to be verified and, trusted; confidence in the validity of a transmission, a message, or message, originator. This means verifying that users are who they say they are and that, each input arriving at the system came from a trusted source., Accountability: The security goal that generates the requirement for actions, of an entity to be traced uniquely to that entity. This supports nonrepudiation, deterrence, fault isolation, intrusion detection and prevention, and afteraction recovery and legal action. Because truly secure systems are not yet an, achievable goal, we must be able to trace a security breach to a responsible, party. Systems must keep records of their activities to permit later forensic, analysis to trace security breaches or to aid in transaction disputes., , Examples, We now provide some examples of applications that illustrate the requirements just, enumerated.2 For these examples, we use three levels of impact on organizations or, individuals should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability). These levels are defined in FIPS PUB 199:, ■, , ■, , ■, , 2, , Low: The loss could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. A limited adverse, effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a degradation in mission capability to an extent and, duration that the organization is able to perform its primary functions, but the, effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in, minor harm to individuals., Moderate: The loss could be expected to have a serious adverse effect on, organizational operations, organizational assets, or individuals. A serious, adverse effect means that, for example, the loss might (i) cause a significant degradation in mission capability to an extent and duration that the, organization is able to perform its primary functions, but the effectiveness, of the functions is significantly reduced; (ii) result in significant damage to, organizational assets; (iii) result in significant financial loss; or (iv) result in, significant harm to individuals that does not involve loss of life or serious,, life-threatening injuries., High: The loss could be expected to have a severe or catastrophic adverse, effect on organizational operations, organizational assets, or individuals., A severe or catastrophic adverse effect means that, for example, the loss, might (i) cause a severe degradation in or loss of mission capability to an, extent and duration that the organization is not able to perform one or more, of its primary functions; (ii) result in major damage to organizational assets;, (iii) result in major financial loss; or (iv) result in severe or catastrophic harm, to individuals involving loss of life or serious, life-threatening injuries., , These examples are taken from a security policy document published by the Information Technology, Security and Privacy Office at Purdue University.
Page 25 :
24, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , CONFIDENTIALITY Student grade information is an asset whose confidentiality is, considered to be highly important by students. In the United States, the release of, such information is regulated by the Family Educational Rights and Privacy Act, (FERPA). Grade information should only be available to students, their parents,, and employees that require the information to do their job. Student enrollment, information may have a moderate confidentiality rating. While still covered by, FERPA, this information is seen by more people on a daily basis, is less likely to be, targeted than grade information, and results in less damage if disclosed. Directory, information, such as lists of students or faculty or departmental lists, may be assigned a low confidentiality rating or indeed no rating. This information is typically, freely available to the public and published on a school’s Web site., INTEGRITY Several aspects of integrity are illustrated by the example of a hospital, patient’s allergy information stored in a database. The doctor should be able to, trust that the information is correct and current. Now suppose that an employee, (e.g., a nurse) who is authorized to view and update this information deliberately, falsifies the data to cause harm to the hospital. The database needs to be restored, to a trusted basis quickly, and it should be possible to trace the error back to the, person responsible. Patient allergy information is an example of an asset with a high, requirement for integrity. Inaccurate information could result in serious harm or, death to a patient and expose the hospital to massive liability., An example of an asset that may be assigned a moderate level of integrity, requirement is a Web site that offers a forum to registered users to discuss some, specific topic. Either a registered user or a hacker could falsify some entries or, deface the Web site. If the forum exists only for the enjoyment of the users, brings, in little or no advertising revenue, and is not used for something important such, as research, then potential damage is not severe. The Web master may experience, some data, financial, and time loss., An example of a low integrity requirement is an anonymous online poll. Many, Web sites, such as news organizations, offer these polls to their users with very few, safeguards. However, the inaccuracy and unscientific nature of such polls is well, understood., AVAILABILITY The more critical a component or service, the higher is the level of, availability required. Consider a system that provides authentication services for, critical systems, applications, and devices. An interruption of service results in the, inability for customers to access computing resources and staff to access the resources they need to perform critical tasks. The loss of the service translates into a, large financial loss in lost employee productivity and potential customer loss., An example of an asset that would typically be rated as having a moderate, availability requirement is a public Web site for a university; the Web site provides, information for current and prospective students and donors. Such a site is not a, critical component of the university’s information system, but its unavailability will, cause some embarrassment., An online telephone directory lookup application would be classified as a low, availability requirement. Although the temporary loss of the application may be, an annoyance, there are other ways to access the information, such as a hardcopy, directory or the operator.
Page 26 :
1.1 / COMPUTER SECURITY CONCEPTS, , 25, , The Challenges of Computer Security, Computer and network security is both fascinating and complex. Some of the, reasons follow:, 1. Security is not as simple as it might first appear to the novice. The requirements seem to be straightforward; indeed, most of the major requirements for, security services can be given self-explanatory, one-word labels: confidentiality, authentication, nonrepudiation, or integrity. But the mechanisms used to, meet those requirements can be quite complex, and understanding them may, involve rather subtle reasoning., 2. In developing a particular security mechanism or algorithm, one must always, consider potential attacks on those security features. In many cases, successful, attacks are designed by looking at the problem in a completely different way,, therefore exploiting an unexpected weakness in the mechanism., 3. Because of point 2, the procedures used to provide particular services are, often counterintuitive. Typically, a security mechanism is complex, and it is not, obvious from the statement of a particular requirement that such elaborate, measures are needed. It is only when the various aspects of the threat are considered that elaborate security mechanisms make sense., 4. Having designed various security mechanisms, it is necessary to decide where, to use them. This is true both in terms of physical placement (e.g., at what points, in a network are certain security mechanisms needed) and in a logical sense, (e.g., at what layer or layers of an architecture such as TCP/IP [Transmission, Control Protocol/Internet Protocol] should mechanisms be placed)., 5. Security mechanisms typically involve more than a particular algorithm or, protocol. They also require that participants be in possession of some secret information (e.g., an encryption key), which raises questions about the creation,, distribution, and protection of that secret information. There also may be a reliance on communications protocols whose behavior may complicate the task, of developing the security mechanism. For example, if the proper functioning, of the security mechanism requires setting time limits on the transit time of a, message from sender to receiver, then any protocol or network that introduces, variable, unpredictable delays may render such time limits meaningless., 6. Computer and network security is essentially a battle of wits between a perpetrator who tries to find holes and the designer or administrator who tries to, close them. The great advantage that the attacker has is that he or she need, only find a single weakness, while the designer must find and eliminate all, weaknesses to achieve perfect security., 7. There is a natural tendency on the part of users and system managers to perceive little benefit from security investment until a security failure occurs., 8. Security requires regular, even constant, monitoring, and this is difficult in, today’s short-term, overloaded environment., 9. Security is still too often an afterthought to be incorporated into a system, after the design is complete rather than being an integral part of the design, process.
Page 27 :
26, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , 10. Many users and even security administrators view strong security as an, impediment to efficient and user-friendly operation of an information system, or use of information., The difficulties just enumerated will be encountered in numerous ways as we, examine the various security threats and mechanisms throughout this book., , 1.2 THE OSI SECURITY ARCHITECTURE, To assess effectively the security needs of an organization and to evaluate and, choose various security products and policies, the manager responsible for security, needs some systematic way of defining the requirements for security and characterizing the approaches to satisfying those requirements. This is difficult enough in a, centralized data processing environment; with the use of local and wide area networks, the problems are compounded., ITU-T3 Recommendation X.800, Security Architecture for OSI, defines such a, systematic approach.4 The OSI security architecture is useful to managers as a way, of organizing the task of providing security. Furthermore, because this architecture, was developed as an international standard, computer and communications vendors, have developed security features for their products and services that relate to this, structured definition of services and mechanisms., For our purposes, the OSI security architecture provides a useful, if abstract,, overview of many of the concepts that this book deals with. The OSI security architecture focuses on security attacks, mechanisms, and services. These can be defined, briefly as, ■, ■, ■, , Security attack: Any action that compromises the security of information, owned by an organization., Security mechanism: A process (or a device incorporating such a process), that is designed to detect, prevent, or recover from a security attack., Security service: A processing or communication service that enhances the, security of the data processing systems and the information transfers of an, organization. The services are intended to counter security attacks, and they, make use of one or more security mechanisms to provide the service., , In the literature, the terms threat and attack are commonly used to mean more, or less the same thing. Table 1.1 provides definitions taken from RFC 4949, Internet, Security Glossary., , 3, , The International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T), is a United Nations-sponsored agency that develops standards, called Recommendations, relating to telecommunications and to open systems interconnection (OSI)., 4, The OSI security architecture was developed in the context of the OSI protocol architecture, which is, described in Appendix L. However, for our purposes in this chapter, an understanding of the OSI protocol architecture is not required.
Page 28 :
1.3 / SECURITY ATTACKS, , 27, , Table 1.1 Threats and Attacks (RFC 4949), Threat, A potential for violation of security, which exists when there is a circumstance, capability, action,, or event that could breach security and cause harm. That is, a threat is a possible danger that might, exploit a vulnerability., Attack, An assault on system security that derives from an intelligent threat; that is, an intelligent act that, is a deliberate attempt (especially in the sense of a method or technique) to evade security services, and violate the security policy of a system., , 1.3 SECURITY ATTACKS, A useful means of classifying security attacks, used both in X.800 and RFC 4949, is, in terms of passive attacks and active attacks (Figure 1.2). A passive attack attempts, to learn or make use of information from the system but does not affect system resources. An active attack attempts to alter system resources or affect their operation., , Passive Attacks, Passive attacks (Figure 1.2a) are in the nature of eavesdropping on, or monitoring, of, transmissions. The goal of the opponent is to obtain information that is being, transmitted. Two types of passive attacks are the release of message contents and, traffic analysis., The release of message contents is easily understood. A telephone conversation, an electronic mail message, and a transferred file may contain sensitive or, confidential information. We would like to prevent an opponent from learning the, contents of these transmissions., A second type of passive attack, traffic analysis, is subtler. Suppose that we, had a way of masking the contents of messages or other information traffic so that, opponents, even if they captured the message, could not extract the information, from the message. The common technique for masking contents is encryption. If we, had encryption protection in place, an opponent might still be able to observe the, pattern of these messages. The opponent could determine the location and identity, of communicating hosts and could observe the frequency and length of messages, being exchanged. This information might be useful in guessing the nature of the, communication that was taking place., Passive attacks are very difficult to detect, because they do not involve any, alteration of the data. Typically, the message traffic is sent and received in an apparently normal fashion, and neither the sender nor receiver is aware that a third party, has read the messages or observed the traffic pattern. However, it is feasible to prevent the success of these attacks, usually by means of encryption. Thus, the emphasis in dealing with passive attacks is on prevention rather than detection., , Active Attacks, Active attacks (Figure 1.2b) involve some modification of the data stream or the, creation of a false stream and can be subdivided into four categories: masquerade,, replay, modification of messages, and denial of service.
Page 29 :
28, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , Darth, , Internet or, other communications facility, Bob, , Alice, (a) Passive attacks, , Darth, , 1, , 2, , 3, Internet or, other communications facility, Alice, , Bob, (b) Active attacks, , Figure 1.2, , Security Attacks, , A masquerade takes place when one entity pretends to be a different entity, (path 2 of Figure 1.2b is active). A masquerade attack usually includes one of the, other forms of active attack. For example, authentication sequences can be captured, and replayed after a valid authentication sequence has taken place, thus enabling an, authorized entity with few privileges to obtain extra privileges by impersonating an, entity that has those privileges., Replay involves the passive capture of a data unit and its subsequent retransmission to produce an unauthorized effect (paths 1, 2, and 3 active)., Modification of messages simply means that some portion of a legitimate message is altered, or that messages are delayed or reordered, to produce an unauthorized effect (paths 1 and 2 active). For example, a message meaning “Allow John, Smith to read confidential file accounts” is modified to mean “Allow Fred Brown to, read confidential file accounts.”, , Hiva-Network.Com
Page 30 :
1.4 / SECURITY SERVICES, , 29, , The denial of service prevents or inhibits the normal use or management of, communications facilities (path 3 active). This attack may have a specific target; for, example, an entity may suppress all messages directed to a particular destination, (e.g., the security audit service). Another form of service denial is the disruption of, an entire network, either by disabling the network or by overloading it with messages so as to degrade performance., Active attacks present the opposite characteristics of passive attacks. Whereas, passive attacks are difficult to detect, measures are available to prevent their success., On the other hand, it is quite difficult to prevent active attacks absolutely because, of the wide variety of potential physical, software, and network vulnerabilities., Instead, the goal is to detect active attacks and to recover from any disruption or, delays caused by them. If the detection has a deterrent effect, it may also contribute, to prevention., , 1.4 SECURITY SERVICES, X.800 defines a security service as a service that is provided by a protocol layer of, communicating open systems and that ensures adequate security of the systems or, of data transfers. Perhaps a clearer definition is found in RFC 4949, which provides, the following definition: a processing or communication service that is provided by, a system to give a specific kind of protection to system resources; security services, implement security policies and are implemented by security mechanisms., X.800 divides these services into five categories and fourteen specific services, (Table 1.2). We look at each category in turn.5, , Authentication, The authentication service is concerned with assuring that a communication is authentic. In the case of a single message, such as a warning or alarm signal, the function, of the authentication service is to assure the recipient that the message is from the, source that it claims to be from. In the case of an ongoing interaction, such as the connection of a terminal to a host, two aspects are involved. First, at the time of connection initiation, the service assures that the two entities are authentic, that is, that each, is the entity that it claims to be. Second, the service must assure that the connection is, not interfered with in such a way that a third party can masquerade as one of the two, legitimate parties for the purposes of unauthorized transmission or reception., Two specific authentication services are defined in X.800:, ■, , 5, , Peer entity authentication: Provides for the corroboration of the identity of a, peer entity in an association. Two entities are considered peers if they implement to same protocol in different systems; for example two TCP modules, in two communicating systems. Peer entity authentication is provided for, , There is no universal agreement about many of the terms used in the security literature. For example, the, term integrity is sometimes used to refer to all aspects of information security. The term authentication is, sometimes used to refer both to verification of identity and to the various functions listed under integrity, in this chapter. Our usage here agrees with both X.800 and RFC 4949.
Page 31 :
30, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , Table 1.2, , Security Services (X.800), AUTHENTICATION, , The assurance that the communicating entity is the, one that it claims to be., Peer Entity Authentication, Used in association with a logical connection to, provide confidence in the identity of the entities, connected., Data-Origin Authentication, In a connectionless transfer, provides assurance that, the source of received data is as claimed., ACCESS CONTROL, The prevention of unauthorized use of a resource, (i.e., this service controls who can have access to a, resource, under what conditions access can occur,, and what those accessing the resource are allowed, to do)., DATA CONFIDENTIALITY, The protection of data from unauthorized, disclosure., Connection Confidentiality, The protection of all user data on a connection., Connectionless Confidentiality, The protection of all user data in a single data block., Selective-Field Confidentiality, The confidentiality of selected fields within the user, data on a connection or in a single data block., Traffic-Flow Confidentiality, The protection of the information that might be, derived from observation of traffic flows., , DATA INTEGRITY, The assurance that data received are exactly as, sent by an authorized entity (i.e., contain no modification, insertion, deletion, or replay)., Connection Integrity with Recovery, Provides for the integrity of all user data on a connection and detects any modification, insertion, deletion,, or replay of any data within an entire data sequence,, with recovery attempted., Connection Integrity without Recovery, As above, but provides only detection without, recovery., Selective-Field Connection Integrity, Provides for the integrity of selected fields within the, user data of a data block transferred over a connection and takes the form of determination of whether, the selected fields have been modified, inserted,, deleted, or replayed., Connectionless Integrity, Provides for the integrity of a single connectionless, data block and may take the form of detection of, data modification. Additionally, a limited form of, replay detection may be provided., Selective-Field Connectionless Integrity, Provides for the integrity of selected fields within a, single connectionless data block; takes the form of, determination of whether the selected fields have, been modified., NONREPUDIATION, Provides protection against denial by one of the, entities involved in a communication of having participated in all or part of the communication., Nonrepudiation, Origin, Proof that the message was sent by the specified, party., Nonrepudiation, Destination, Proof that the message was received by the specified, party., , ■, , use at the establishment of, or at times during the data transfer phase of, a, connection. It attempts to provide confidence that an entity is not performing, either a masquerade or an unauthorized replay of a previous connection., Data origin authentication: Provides for the corroboration of the source of a, data unit. It does not provide protection against the duplication or modification of data units. This type of service supports applications like electronic mail,, where there are no prior interactions between the communicating entities.
Page 32 :
1.4 / SECURITY SERVICES, , 31, , Access Control, In the context of network security, access control is the ability to limit and control, the access to host systems and applications via communications links. To achieve, this, each entity trying to gain access must first be identified, or authenticated,, so that access rights can be tailored to the individual., , Data Confidentiality, Confidentiality is the protection of transmitted data from passive attacks. With respect to the content of a data transmission, several levels of protection can be identified. The broadest service protects all user data transmitted between two users, over a period of time. For example, when a TCP connection is set up between two, systems, this broad protection prevents the release of any user data transmitted over, the TCP connection. Narrower forms of this service can also be defined, including, the protection of a single message or even specific fields within a message. These, refinements are less useful than the broad approach and may even be more complex, and expensive to implement., The other aspect of confidentiality is the protection of traffic flow from, analysis. This requires that an attacker not be able to observe the source and destination, frequency, length, or other characteristics of the traffic on a communications, facility., , Data Integrity, As with confidentiality, integrity can apply to a stream of messages, a single message, or selected fields within a message. Again, the most useful and straightforward, approach is total stream protection., A connection-oriented integrity service, one that deals with a stream of messages, assures that messages are received as sent with no duplication, insertion,, modification, reordering, or replays. The destruction of data is also covered under, this service. Thus, the connection-oriented integrity service addresses both message stream modification and denial of service. On the other hand, a connectionless integrity service, one that deals with individual messages without regard to any, larger context, generally provides protection against message modification only., We can make a distinction between service with and without recovery. Because, the integrity service relates to active attacks, we are concerned with detection rather, than prevention. If a violation of integrity is detected, then the service may simply, report this violation, and some other portion of software or human intervention is, required to recover from the violation. Alternatively, there are mechanisms available to recover from the loss of integrity of data, as we will review subsequently. The, incorporation of automated recovery mechanisms is, in general, the more attractive, alternative., , Nonrepudiation, Nonrepudiation prevents either sender or receiver from denying a transmitted message. Thus, when a message is sent, the receiver can prove that the alleged sender in, fact sent the message. Similarly, when a message is received, the sender can prove, that the alleged receiver in fact received the message.
Page 33 :
32, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , Availability Service, Both X.800 and RFC 4949 define availability to be the property of a system or a, system resource being accessible and usable upon demand by an authorized system, entity, according to performance specifications for the system (i.e., a system is available if it provides services according to the system design whenever users request, them). A variety of attacks can result in the loss of or reduction in availability. Some, of these attacks are amenable to automated countermeasures, such as authentication and encryption, whereas others require some sort of physical action to prevent, or recover from loss of availability of elements of a distributed system., X.800 treats availability as a property to be associated with various security, services. However, it makes sense to call out specifically an availability service. An, availability service is one that protects a system to ensure its availability. This service addresses the security concerns raised by denial-of-service attacks. It depends, on proper management and control of system resources and thus depends on access, control service and other security services., , 1.5 SECURITY MECHANISMS, Table 1.3 lists the security mechanisms defined in X.800. The mechanisms are, divided into those that are implemented in a specific protocol layer, such as TCP or, an application-layer protocol, and those that are not specific to any particular protocol layer or security service. These mechanisms will be covered in the appropriate, Table 1.3, , Security Mechanisms (X.800), , SPECIFIC SECURITY MECHANISMS, May be incorporated into the appropriate protocol, layer in order to provide some of the OSI security, services., Encipherment, The use of mathematical algorithms to transform, data into a form that is not readily intelligible. The, transformation and subsequent recovery of the data, depend on an algorithm and zero or more encryption, keys., Digital Signature, Data appended to, or a cryptographic transformation, of, a data unit that allows a recipient of the data unit, to prove the source and integrity of the data unit and, protect against forgery (e.g., by the recipient)., Access Control, A variety of mechanisms that enforce access rights to, resources., Data Integrity, A variety of mechanisms used to assure the integrity, of a data unit or stream of data units., , PERVASIVE SECURITY MECHANISMS, Mechanisms that are not specific to any particular, OSI security service or protocol layer., Trusted Functionality, That which is perceived to be correct with respect, to some criteria (e.g., as established by a security, policy)., Security Label, The marking bound to a resource (which may be a, data unit) that names or designates the security attributes of that resource., Event Detection, Detection of security-relevant events., Security Audit Trail, Data collected and potentially used to facilitate a, security audit, which is an independent review and, examination of system records and activities., Security Recovery, Deals with requests from mechanisms, such as event, handling and management functions, and takes, recovery actions.
Page 34 :
1.5 / SECURITY MECHANISMS, , 33, , SPECIFIC SECURITY MECHANISMS, Authentication Exchange, A mechanism intended to ensure the identity of an, entity by means of information exchange., Traffic Padding, The insertion of bits into gaps in a data stream to, frustrate traffic analysis attempts., Routing Control, Enables selection of particular physically secure, routes for certain data and allows routing changes,, especially when a breach of security is suspected., Notarization, The use of a trusted third party to assure certain, properties of a data exchange., , places in the book. So we do not elaborate now, except to comment on the definition of encipherment. X.800 distinguishes between reversible encipherment mechanisms and irreversible encipherment mechanisms. A reversible encipherment, mechanism is simply an encryption algorithm that allows data to be encrypted and, subsequently decrypted. Irreversible encipherment mechanisms include hash algorithms and message authentication codes, which are used in digital signature and, message authentication applications., Table 1.4, based on one in X.800, indicates the relationship between security, services and security mechanisms., Table 1.4 Relationship Between Security Services and Mechanisms, , SERVICE, , En, ci, p, D her, m, ig, ita en, A l si t, cc, g, es nat, D s co ure, at, a ntro, A inte l, ut, he grit, Tr ntic y, affi at, io, c, Ro pa n e, ut dd xch, in, i, N ng c g ang, ot, e, o, ar nt, r, iz, at ol, io, n, , MECHANISM, , Peer entity authentication, , Y, , Y, , Data origin authentication, , Y, , Y, , Access control, , Y, , Confidentiality, , Y, , Traffic flow confidentiality, , Y, , Data integrity, , Y, , Nonrepudiation, Availability, , Y, , Y, Y, Y, , Y, , Y, , Y, Y, , Y, , Y, Y
Page 35 :
34, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , 1.6 FUNDAMENTAL SECURITY DESIGN PRINCIPLES, Despite years of research and development, it has not been possible to develop, security design and implementation techniques that systematically exclude security, flaws and prevent all unauthorized actions. In the absence of such foolproof techniques, it is useful to have a set of widely agreed design principles that can guide, the development of protection mechanisms. The National Centers of Academic, Excellence in Information Assurance/Cyber Defense, which is jointly sponsored by, the U.S. National Security Agency and the U.S. Department of Homeland Security,, list the following as fundamental security design principles [NCAE13]:, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, , Economy of mechanism, Fail-safe defaults, Complete mediation, Open design, Separation of privilege, Least privilege, Least common mechanism, Psychological acceptability, Isolation, Encapsulation, Modularity, Layering, Least astonishment, , The first eight listed principles were first proposed in [SALT75] and have withstood, the test of time. In this section, we briefly discuss each principle., Economy of mechanism means that the design of security measures embodied in both hardware and software should be as simple and small as possible., The motivation for this principle is that relatively simple, small design is easier to test and verify thoroughly. With a complex design, there are many more, opportunities for an adversary to discover subtle weaknesses to exploit that may, be difficult to spot ahead of time. The more complex the mechanism, the more, likely it is to possess exploitable flaws. Simple mechanisms tend to have fewer, exploitable flaws and require less maintenance. Further, because configuration, management issues are simplified, updating or replacing a simple mechanism, becomes a less intensive process. In practice, this is perhaps the most difficult, principle to honor. There is a constant demand for new features in both hardware and software, complicating the security design task. The best that can be, done is to keep this principle in mind during system design to try to eliminate, unnecessary complexity., Fail-safe defaults means that access decisions should be based on permission, rather than exclusion. That is, the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. This approach
Page 36 :
1.6 / FUNDAMENTAL SECURITY DESIGN PRINCIPLES, , 35, , exhibits a better failure mode than the alternative approach, where the default is, to permit access. A design or implementation mistake in a mechanism that gives, explicit permission tends to fail by refusing permission, a safe situation that can, be quickly detected. On the other hand, a design or implementation mistake in a, mechanism that explicitly excludes access tends to fail by allowing access, a failure, that may long go unnoticed in normal use. Most file access systems and virtually all, protected services on client/server systems use fail-safe defaults., Complete mediation means that every access must be checked against the, access control mechanism. Systems should not rely on access decisions retrieved, from a cache. In a system designed to operate continuously, this principle requires, that, if access decisions are remembered for future use, careful consideration be, given to how changes in authority are propagated into such local memories. File, access systems appear to provide an example of a system that complies with this, principle. However, typically, once a user has opened a file, no check is made to see, if permissions change. To fully implement complete mediation, every time a user, reads a field or record in a file, or a data item in a database, the system must exercise, access control. This resource-intensive approach is rarely used., Open design means that the design of a security mechanism should be open, rather than secret. For example, although encryption keys must be secret, encryption, algorithms should be open to public scrutiny. The algorithms can then be reviewed, by many experts, and users can therefore have high confidence in them. This is the, philosophy behind the National Institute of Standards and Technology (NIST), program of standardizing encryption and hash algorithms, and has led to the widespread adoption of NIST-approved algorithms., Separation of privilege is defined in [SALT75] as a practice in which multiple privilege attributes are required to achieve access to a restricted resource., A good example of this is multifactor user authentication, which requires the use of, multiple techniques, such as a password and a smart card, to authorize a user. The, term is also now applied to any technique in which a program is divided into parts, that are limited to the specific privileges they require in order to perform a specific, task. This is used to mitigate the potential damage of a computer security attack., One example of this latter interpretation of the principle is removing high privilege, operations to another process and running that process with the higher privileges, required to perform its tasks. Day-to-day interfaces are executed in a lower privileged process., Least privilege means that every process and every user of the system should, operate using the least set of privileges necessary to perform the task. A good, example of the use of this principle is role-based access control. The system security, policy can identify and define the various roles of users or processes. Each role is, assigned only those permissions needed to perform its functions. Each permission, specifies a permitted access to a particular resource (such as read and write access, to a specified file or directory, connect access to a given host and port). Unless a, permission is granted explicitly, the user or process should not be able to access the, protected resource. More generally, any access control system should allow each, user only the privileges that are authorized for that user. There is also a temporal, aspect to the least privilege principle. For example, system programs or administrators who have special privileges should have those privileges only when necessary;
Page 37 :
36, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , when they are doing ordinary activities the privileges should be withdrawn. Leaving, them in place just opens the door to accidents., Least common mechanism means that the design should minimize the functions shared by different users, providing mutual security. This principle helps, reduce the number of unintended communication paths and reduces the amount of, hardware and software on which all users depend, thus making it easier to verify if, there are any undesirable security implications., Psychological acceptability implies that the security mechanisms should not, interfere unduly with the work of users, while at the same time meeting the needs of, those who authorize access. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms. Where possible,, security mechanisms should be transparent to the users of the system or at most, introduce minimal obstruction. In addition to not being intrusive or burdensome,, security procedures must reflect the user’s mental model of protection. If the protection procedures do not make sense to the user or if the user must translate his image, of protection into a substantially different protocol, the user is likely to make errors., Isolation is a principle that applies in three contexts. First, public access systems should be isolated from critical resources (data, processes, etc.) to prevent disclosure or tampering. In cases where the sensitivity or criticality of the information, is high, organizations may want to limit the number of systems on which that data is, stored and isolate them, either physically or logically. Physical isolation may include, ensuring that no physical connection exists between an organization’s public access, information resources and an organization’s critical information. When implementing logical isolation solutions, layers of security services and mechanisms should be, established between public systems and secure systems responsible for protecting, critical resources. Second, the processes and files of individual users should be isolated from one another except where it is explicitly desired. All modern operating, systems provide facilities for such isolation, so that individual users have separate,, isolated process space, memory space, and file space, with protections for preventing unauthorized access. And finally, security mechanisms should be isolated in the, sense of preventing access to those mechanisms. For example, logical access control, may provide a means of isolating cryptographic software from other parts of the, host system and for protecting cryptographic software from tampering and the keys, from replacement or disclosure., Encapsulation can be viewed as a specific form of isolation based on objectoriented functionality. Protection is provided by encapsulating a collection of procedures and data objects in a domain of its own so that the internal structure of a, data object is accessible only to the procedures of the protected subsystem, and the, procedures may be called only at designated domain entry points., Modularity in the context of security refers both to the development of security, functions as separate, protected modules and to the use of a modular architecture for, mechanism design and implementation. With respect to the use of separate security, modules, the design goal here is to provide common security functions and services,, such as cryptographic functions, as common modules. For example, numerous protocols and applications make use of cryptographic functions. Rather than implementing such functions in each protocol or application, a more secure design is provided, by developing a common cryptographic module that can be invoked by numerous
Page 38 :
1.7 / ATTACK SURFACES AND ATTACK TREES, , 37, , protocols and applications. The design and implementation effort can then focus on, the secure design and implementation of a single cryptographic module and including mechanisms to protect the module from tampering. With respect to the use of a, modular architecture, each security mechanism should be able to support migration, to new technology or upgrade of new features without requiring an entire system, redesign. The security design should be modular so that individual parts of the security design can be upgraded without the requirement to modify the entire system., Layering refers to the use of multiple, overlapping protection approaches, addressing the people, technology, and operational aspects of information systems., By using multiple, overlapping protection approaches, the failure or circumvention of any individual protection approach will not leave the system unprotected., We will see throughout this book that a layering approach is often used to provide, multiple barriers between an adversary and protected information or services. This, technique is often referred to as defense in depth., Least astonishment means that a program or user interface should always, respond in the way that is least likely to astonish the user. For example, the mechanism, for authorization should be transparent enough to a user that the user has a good intuitive understanding of how the security goals map to the provided security mechanism., , 1.7 ATTACK SURFACES AND ATTACK TREES, In Section 1.3, we provided an overview of the spectrum of security threats and, attacks facing computer and network systems. Section 22.1 goes into more detail, about the nature of attacks and the types of adversaries that present security threats., In this section, we elaborate on two concepts that are useful in evaluating and classifying threats: attack surfaces and attack trees., , Attack Surfaces, An attack surface consists of the reachable and exploitable vulnerabilities in a system [MANA11, HOWA03]. Examples of attack surfaces are the following:, ■, ■, ■, ■, ■, , Open ports on outward facing Web and other servers, and code listening on, those ports, Services available on the inside of a firewall, Code that processes incoming data, email, XML, office documents, and industry-specific custom data exchange formats, Interfaces, SQL, and Web forms, An employee with access to sensitive information vulnerable to a social, engineering attack, Attack surfaces can be categorized as follows:, , ■, , Network attack surface: This category refers to vulnerabilities over an enterprise, network, wide-area network, or the Internet. Included in this category are network protocol vulnerabilities, such as those used for a denial-of-service attack,, disruption of communications links, and various forms of intruder attacks., , Hiva-Network.Com
Page 39 :
CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, ■, , ■, , Software attack surface: This refers to vulnerabilities in application, utility,, or operating system code. A particular focus in this category is Web server, software., Human attack surface: This category refers to vulnerabilities created by, personnel or outsiders, such as social engineering, human error, and trusted, insiders., , An attack surface analysis is a useful technique for assessing the scale and, severity of threats to a system. A systematic analysis of points of vulnerability, makes developers and security analysts aware of where security mechanisms are, required. Once an attack surface is defined, designers may be able to find ways to, make the surface smaller, thus making the task of the adversary more difficult. The, attack surface also provides guidance on setting priorities for testing, strengthening, security measures, and modifying the service or application., As illustrated in Figure 1.3, the use of layering, or defense in depth, and attack, surface reduction complement each other in mitigating security risk., , Attack Trees, , Shallow, , Medium, security risk, , High, security risk, , Deep, , An attack tree is a branching, hierarchical data structure that represents a set of potential techniques for exploiting security vulnerabilities [MAUW05, MOOR01, SCHN99]., The security incident that is the goal of the attack is represented as the root node of, the tree, and the ways that an attacker could reach that goal are iteratively and incrementally represented as branches and subnodes of the tree. Each subnode defines a, subgoal, and each subgoal may have its own set of further subgoals, and so on. The, final nodes on the paths outward from the root, that is, the leaf nodes, represent different ways to initiate an attack. Each node other than a leaf is either an AND-node or an, OR-node. To achieve the goal represented by an AND-node, the subgoals represented, by all of that node’s subnodes must be achieved; and for an OR-node, at least one of, the subgoals must be achieved. Branches can be labeled with values representing difficulty, cost, or other attack attributes, so that alternative attacks can be compared., , Low, security risk, , Medium, security risk, , Small, , Large, , Layering, , 38, , Attack surface, , Figure 1.3, , Defense in Depth and Attack Surface
Page 40 :
1.7 / ATTACK SURFACES AND ATTACK TREES, , 39, , The motivation for the use of attack trees is to effectively exploit the information available on attack patterns. Organizations such as CERT publish security, advisories that have enabled the development of a body of knowledge about both, general attack strategies and specific attack patterns. Security analysts can use the, attack tree to document security attacks in a structured form that reveals key vulnerabilities. The attack tree can guide both the design of systems and applications,, and the choice and strength of countermeasures., Figure 1.4, based on a figure in [DIMI07], is an example of an attack tree, analysis for an Internet banking authentication application. The root of the tree is, the objective of the attacker, which is to compromise a user’s account. The shaded, boxes on the tree are the leaf nodes, which represent events that comprise the, attacks. Note that in this tree, all the nodes other than leaf nodes are OR-nodes., The analysis to generate this tree considered the three components involved in, authentication:, , Bank account compromise, User credential compromise, , UT/U1a User surveillance, UT/U1b Theft of token and, handwritten notes, Malicious software, installation, UT/U3a Smartcard analyzers, UT/U3b Smartcard reader, manipulator, UT/U3c Brute force attacks, with PIN calculators, , Vulnerability exploit, UT/U2a Hidden code, UT/U2b Worms, UT/U2c Emails with, malicious code, , CC2 Sniffing, User communication, with attacker, , UT/U4a Social engineering, UT/U4b Web page, obfuscation, , Injection of commands, , CC3 Active man-in-the, middle attacks, , User credential guessing, , IBS1 Brute force attacks, , IBS2 Security policy, violation, Use of known authenticated, session by attacker, , Redirection of, communication toward, fraudulent site, CC1 Pharming, IBS3 Web site manipulation, , Normal user authentication, with specified session ID, , Figure 1.4 An Attack Tree for Internet Banking Authentication, , CC4 Pre-defined session, IDs (session hijacking)
Page 41 :
40, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, ■, , ■, ■, , User terminal and user (UT/U): These attacks target the user equipment,, including the tokens that may be involved, such as smartcards or other password generators, as well as the actions of the user., Communications channel (CC): This type of attack focuses on communication links., Internet banking server (IBS): These types of attacks are offline attacks against, the servers that host the Internet banking application., , Five overall attack strategies can be identified, each of which exploits one or, more of the three components. The five strategies are as follows:, ■, , ■, , ■, , ■, , ■, , User credential compromise: This strategy can be used against many elements of the attack surface. There are procedural attacks, such as monitoring, a user’s action to observe a PIN or other credential, or theft of the user’s, token or handwritten notes. An adversary may also compromise token, information using a variety of token attack tools, such as hacking the smartcard or using a brute force approach to guess the PIN. Another possible, strategy is to embed malicious software to compromise the user’s login and, password. An adversary may also attempt to obtain credential information, via the communication channel (sniffing). Finally, an adversary may use, various means to engage in communication with the target user, as shown, in Figure 1.4., Injection of commands: In this type of attack, the attacker is able to intercept, communication between the UT and the IBS. Various schemes can be used, to be able to impersonate the valid user and so gain access to the banking, system., User credential guessing: It is reported in [HILT06] that brute force attacks, against some banking authentication schemes are feasible by sending random usernames and passwords. The attack mechanism is based on distributed, zombie personal computers, hosting automated programs for username- or, password-based calculation., Security policy violation: For example, violating the bank’s security policy, in combination with weak access control and logging mechanisms, an employee may cause an internal security incident and expose a customer’s, account., Use of known authenticated session: This type of attack persuades or forces, the user to connect to the IBS with a preset session ID. Once the user authenticates to the server, the attacker may utilize the known session ID to send, packets to the IBS, spoofing the user’s identity., , Figure 1.4 provides a thorough view of the different types of attacks on an, Internet banking authentication application. Using this tree as a starting point, security analysts can assess the risk of each attack and, using the design principles outlined in the preceding section, design a comprehensive security facility. [DIMO07], provides a good account of the results of this design effort.
Page 42 :
1.8 / A MODEL FOR NETWORK SECURITY, , 41, , 1.8 A MODEL FOR NETWORK SECURITY, A model for much of what we will be discussing is captured, in very general terms, in, Figure 1.5. A message is to be transferred from one party to another across some sort, of Internet service. The two parties, who are the principals in this transaction, must, cooperate for the exchange to take place. A logical information channel is established, by defining a route through the Internet from source to destination and by the cooperative use of communication protocols (e.g., TCP/IP) by the two principals., Security aspects come into play when it is necessary or desirable to protect the, information transmission from an opponent who may present a threat to confidentiality,, authenticity, and so on. All the techniques for providing security have two components:, ■, , ■, , A security-related transformation on the information to be sent. Examples, include the encryption of the message, which scrambles the message so that it, is unreadable by the opponent, and the addition of a code based on the contents of the message, which can be used to verify the identity of the sender., Some secret information shared by the two principals and, it is hoped,, unknown to the opponent. An example is an encryption key used in conjunction with the transformation to scramble the message before transmission, and unscramble it on reception.6, , A trusted third party may be needed to achieve secure transmission. For, example, a third party may be responsible for distributing the secret information, Trusted third party, (e.g., arbiter, distributer, of secret information), , Secure, message, , Secure, message, , Message, , Security-related, transformation, , Recipient, , Information, channel, , Secret, information, , Security-related, transformation, , Message, , Sender, , Secret, information, , Opponent, Figure 1.5 Model for Network Security, 6, , Part Two discusses a form of encryption, known as a symmetric encryption, in which only one of the two, principals needs to have the secret information.
Page 43 :
42, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, , to the two principals while keeping it from any opponent. Or a third party may be, needed to arbitrate disputes between the two principals concerning the authenticity, of a message transmission., This general model shows that there are four basic tasks in designing a particular security service:, 1. Design an algorithm for performing the security-related transformation. The, algorithm should be such that an opponent cannot defeat its purpose., 2. Generate the secret information to be used with the algorithm., 3. Develop methods for the distribution and sharing of the secret information., 4. Specify a protocol to be used by the two principals that makes use of the, security algorithm and the secret information to achieve a particular security, service., Parts One through Five of this book concentrate on the types of security, mechanisms and services that fit into the model shown in Figure 1.5. However,, there are other security-related situations of interest that do not neatly fit this, model but are considered in this book. A general model of these other situations, is illustrated in Figure 1.6, which reflects a concern for protecting an information, system from unwanted access. Most readers are familiar with the concerns caused, by the existence of hackers, who attempt to penetrate systems that can be accessed, over a network. The hacker can be someone who, with no malign intent, simply gets, satisfaction from breaking and entering a computer system. The intruder can be a, disgruntled employee who wishes to do damage or a criminal who seeks to exploit, computer assets for financial gain (e.g., obtaining credit card numbers or performing illegal money transfers)., Another type of unwanted access is the placement in a computer system of, logic that exploits vulnerabilities in the system and that can affect application programs as well as utility programs, such as editors and compilers. Programs can present two kinds of threats:, ■, ■, , Information access threats: Intercept or modify data on behalf of users who, should not have access to that data., Service threats: Exploit service flaws in computers to inhibit use by legitimate, users., Information system, Computing resources, (processor, memory, I/O), , Opponent, —human (e.g., hacker), , Data, , —software, (e.g., virus, worm), , Processes, , Access channel, Gatekeeper, function, Figure 1.6, , Network Access Security Model, , Software, Internal security controls
Page 44 :
1.9 / STANDARDS, , 43, , Viruses and worms are two examples of software attacks. Such attacks can be, introduced into a system by means of a disk that contains the unwanted logic concealed in otherwise useful software. They can also be inserted into a system across a, network; this latter mechanism is of more concern in network security., The security mechanisms needed to cope with unwanted access fall into two, broad categories (see Figure 1.6). The first category might be termed a gatekeeper, function. It includes password-based login procedures that are designed to deny, access to all but authorized users and screening logic that is designed to detect and, reject worms, viruses, and other similar attacks. Once either an unwanted user, or unwanted software gains access, the second line of defense consists of a variety of internal controls that monitor activity and analyze stored information in an, attempt to detect the presence of unwanted intruders. These issues are explored, in Part Six., , 1.9 STANDARDS, Many of the security techniques and applications described in this book have been, specified as standards. Additionally, standards have been developed to cover management practices and the overall architecture of security mechanisms and services., Throughout this book, we describe the most important standards in use or that are, being developed for various aspects of cryptography and network security. Various, organizations have been involved in the development or promotion of these standards. The most important (in the current context) of these organizations are as, follows:, ■, , ■, , ■, , National Institute of Standards and Technology: NIST is a U.S. federal agency, that deals with measurement science, standards, and technology related to, U.S. government use and to the promotion of U.S. private-sector innovation., Despite its national scope, NIST Federal Information Processing Standards, (FIPS) and Special Publications (SP) have a worldwide impact., Internet Society: ISOC is a professional membership society with worldwide organizational and individual membership. It provides leadership in, addressing issues that confront the future of the Internet and is the organization home for the groups responsible for Internet infrastructure standards,, including the Internet Engineering Task Force (IETF) and the Internet, Architecture Board (IAB). These organizations develop Internet standards and related specifications, all of which are published as Requests for, Comments (RFCs)., ITU-T: The International Telecommunication Union (ITU) is an international organization within the United Nations System in which governments, and the private sector coordinate global telecom networks and services. The, ITU Telecommunication Standardization Sector (ITU-T) is one of the three, sectors of the ITU. ITU-T’s mission is the development of technical standards, covering all fields of telecommunications. ITU-T standards are referred to as, Recommendations.
Page 45 :
44, , CHAPTER 1 / COMPUTER AND NETWORK SECURITY CONCEPTS, ■, , ISO: The International Organization for Standardization (ISO)7 is a worldwide federation of national standards bodies from more than 140 countries,, one from each country. ISO is a nongovernmental organization that promotes, the development of standardization and related activities with a view to facilitating the international exchange of goods and services and to developing, cooperation in the spheres of intellectual, scientific, technological, and economic activity. ISO’s work results in international agreements that are published as International Standards., , A more detailed discussion of these organizations is contained in Appendix D., , 1.10 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, access control, active attack, authentication, authenticity, availability, data confidentiality, data integrity, , denial of service, encryption, integrity, intruder, masquerade, nonrepudiation, OSI security architecture, , passive attack, replay, security attacks, security mechanisms, security services, traffic analysis, , Review Questions, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, , What is the OSI security architecture?, List and briefly define the three key objectives of computer security., List and briefly define categories of passive and active security attacks., List and briefly define categories of security services., List and briefly define categories of security mechanisms., List and briefly define the fundamental security design principles., Explain the difference between an attack surface and an attack tree., , Problems, 1.1, , 1.2, , 7, , Consider an automated cash deposit machine in which users provide a card or an account number to deposit cash. Give examples of confidentiality, integrity, and availability requirements associated with the system, and, in each case, indicate the degree, of importance of the requirement., Repeat Problem 1.1 for a payment gateway system where a user pays for an item, using their account via the payment gateway., , ISO is not an acronym (in which case it would be IOS), but it is a word, derived from the Greek, meaning equal.
Page 46 :
1.10 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 1.3, , 1.4, , 1.5, 1.6, 1.7, 1.8, , 1.9, , 45, , Consider a financial report publishing system used to produce reports for various, organizations., a. Give an example of a type of publication in which confidentiality of the stored, data is the most important requirement., b. Give an example of a type of publication in which data integrity is the most important requirement., c. Give an example in which system availability is the most important requirement., For each of the following assets, assign a low, moderate, or high impact level for the, loss of confidentiality, availability, and integrity, respectively. Justify your answers., a. A student maintaining a blog to post public information., b. An examination section of a university that is managing sensitive information, about exam papers., c. An information system in a pathological laboratory maintaining the patient’s data., d. A student information system used for maintaining student data in a university, that contains both personal, academic information and routine administrative information (not privacy related). Assess the impact for the two data sets separately, and the information system as a whole., e. A University library contains a library management system which controls the, distribution of books amongst the students of various departments. The library, management system contains both the student data and the book data. Assess the, impact for the two data sets separately and the information system as a whole., Draw a matrix similar to Table 1.4 that shows the relationship between security services and attacks., Draw a matrix similar to Table 1.4 that shows the relationship between security, mechanisms and attacks., Develop an attack tree for gaining access to the contents of a physical safe., Consider a company whose operations are housed in two buildings on the same property; one building is headquarters, the other building contains network and computer, services. The property is physically protected by a fence around the perimeter, and, the only entrance to the property is through this fenced perimeter. In addition to, the perimeter fence, physical security consists of a guarded front gate. The local networks are split between the Headquarters’ LAN and the Network Services’ LAN., Internet users connect to the Web server through a firewall. Dial-up users get access, to a particular server on the Network Services’ LAN. Develop an attack tree in which, the root node represents disclosure of proprietary secrets. Include physical, social, engineering, and technical attacks. The tree may contain both AND and OR nodes., Develop a tree that has at least 15 leaf nodes., Read all of the classic papers cited in the Recommended Reading section for this, chapter, available at the Author Web site at WilliamStallings.com/Cryptography. The, papers are available at box.com/Crypto7e. Compose a 500–1000 word paper (or 8–12, slide PowerPoint presentation) that summarizes the key concepts that emerge from, these papers, emphasizing concepts that are common to most or all of the papers.
Page 47 :
CHAPTER, , Introduction to Number Theory, 2.1, , Divisibility and The Division Algorithm, Divisibility, The Division Algorithm, , 2.2, , The Euclidean Algorithm, Greatest Common Divisor, Finding the Greatest Common Divisor, , 2.3, , Modular Arithmetic, The Modulus, Properties of Congruences, Modular Arithmetic Operations, Properties of Modular Arithmetic, Euclidean Algorithm Revisited, The Extended Euclidean Algorithm, , 2.4, , Prime Numbers, , 2.5, , Fermat’s and Euler’s Theorems, Fermat’s Theorem, Euler’s Totient Function, Euler’s Theorem, , 2.6, , Testing for Primality, Miller–Rabin Algorithm, A Deterministic Primality Algorithm, Distribution of Primes, , 2.7, , The Chinese Remainder Theorem, , 2.8, , Discrete Logarithms, The Powers of an Integer, Modulo n, Logarithms for Modular Arithmetic, Calculation of Discrete Logarithms, , 2.9, , Key Terms, Review Questions, and Problems, , Appendix 2A The Meaning of Mod, , 46, Hiva-Network.Com
Page 48 :
2.1 / DIVISIBILITY AND THE DIVISION ALGORITHM, , 47, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Understand the concept of divisibility and the division algorithm., ◆ Understand how to use the Euclidean algorithm to find the greatest common divisor., ◆ Present an overview of the concepts of modular arithmetic., ◆ Explain the operation of the extended Euclidean algorithm., ◆ Discuss key concepts relating to prime numbers., ◆ Understand Fermat’s theorem., ◆ Understand Euler’s theorem., ◆ Define Euler’s totient function., ◆ Make a presentation on the topic of testing for primality., ◆ Explain the Chinese remainder theorem., ◆ Define discrete logarithms., , Number theory is pervasive in cryptographic algorithms. This chapter provides, sufficient breadth and depth of coverage of relevant number theory topics for understanding the wide range of applications in cryptography. The reader familiar with these, topics can safely skip this chapter., The first three sections introduce basic concepts from number theory that are, needed for understanding finite fields; these include divisibility, the Euclidian algorithm, and modular arithmetic. The reader may study these sections now or wait until, ready to tackle Chapter 5 on finite fields., Sections 2.4 through 2.8 discuss aspects of number theory related to prime numbers and discrete logarithms. These topics are fundamental to the design of asymmetric, (public-key) cryptographic algorithms. The reader may study these sections now or, wait until ready to read Part Three., The concepts and techniques of number theory are quite abstract, and it is often, difficult to grasp them intuitively without examples. Accordingly, this chapter includes, a number of examples, each of which is highlighted in a shaded box., , 2.1 DIVISIBILITY AND THE DIVISION ALGORITHM, Divisibility, We say that a nonzero b divides a if a = mb for some m, where a, b, and m are, integers. That is, b divides a if there is no remainder on division. The notation b a, is commonly used to mean b divides a. Also, if b a, we say that b is a divisor of a.
Page 49 :
48, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , The positive divisors of 24 are 1, 2, 3, 4, 6, 8, 12, and 24., 13 182; -5 30; 17 289; -3 33; 17 0, Subsequently, we will need some simple properties of divisibility for integers,, which are as follows:, ■, ■, ■, ■, , If a 1, then a = {1., If a b and b a, then a = {b., Any b ≠ 0 divides 0., If a b and b c, then a c:, 11 66 and 66 198 1 11 198, , ■, , If b g and b h, then b (mg + nh) for arbitrary integers m and n., , To see this last point, note that, ■, ■, , If b g, then g is of the form g = b * g1 for some integer g1., If b h, then h is of the form h = b * h1 for some integer h1., , So, mg + nh = mbg1 + nbh1 = b * (mg1 + nh1), and therefore b divides mg + nh., b = 7; g = 14; h = 63; m = 3; n = 2, 7 14 and 7 63., To show 7 (3 * 14 + 2 * 63),, we have (3 * 14 + 2 * 63) = 7(3 * 2 + 2 * 9),, and it is obvious that 7 (7(3 * 2 + 2 * 9))., , The Division Algorithm, Given any positive integer n and any nonnegative integer a, if we divide a by n,, we get an integer quotient q and an integer remainder r that obey the following, relationship:, a = qn + r, , 0 … r 6 n; q = : a/n ;, , (2.1), , where : x ; is the largest integer less than or equal to x. Equation (2.1) is referred to, as the division algorithm.1, 1, , Equation (2.1) expresses a theorem rather than an algorithm, but by tradition, this is referred to as the, division algorithm.
Page 50 :
2.2 / THE EUCLIDEAN ALGORITHM, , 49, , n, n, , 2n, , qn, , 3n, , a, , (q + 1)n, , 0, r, , (a) General relationship, , 15, , 0, , 15, , 30, = 2 × 15, , 45, = 3 × 15, , 60, = 4 × 15, , (b) Example: 70 = (4 × 15) + 10, , 70, , 75, = 5 × 15, , 10, , Figure 2.1 The Relationship a = qn + r; 0 … r 6 n, , Figure 2.1a demonstrates that, given a and positive n, it is always possible to, find q and r that satisfy the preceding relationship. Represent the integers on the, number line; a will fall somewhere on that line (positive a is shown, a similar demonstration can be made for negative a). Starting at 0, proceed to n, 2n, up to qn, such, that qn … a and (q + 1)n 7 a. The distance from qn to a is r, and we have found, the unique values of q and r. The remainder r is often referred to as a residue., , a = 11;, a = -11;, , n = 7;, n = 7;, , 11 = 1 * 7 + 4;, -11 = ( -2) * 7 + 3;, , r = 4, r = 3, , q = 1, q = -2, , Figure 2.1b provides another example., , 2.2 THE EUCLIDEAN ALGORITHM, One of the basic techniques of number theory is the Euclidean algorithm, which, is a simple procedure for determining the greatest common divisor of two positive, integers. First, we need a simple definition: Two integers are relatively prime if and, only if their only common positive integer factor is 1., , Greatest Common Divisor, Recall that nonzero b is defined to be a divisor of a if a = mb for some m, where, a, b, and m are integers. We will use the notation gcd(a, b) to mean the greatest, common divisor of a and b. The greatest common divisor of a and b is the largest, integer that divides both a and b. We also define gcd(0, 0) = 0.
Page 51 :
50, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , More formally, the positive integer c is said to be the greatest common divisor, of a and b if, 1. c is a divisor of a and of b., 2. any divisor of a and b is a divisor of c., An equivalent definition is the following:, gcd(a, b) = max[k, such that k a and k b], Because we require that the greatest common divisor be positive, gcd(a, b) =, gcd(a, -b) = gcd(-a, b) = gcd(-a, -b). In general, gcd(a, b) = gcd( a , b )., gcd(60, 24) = gcd(60, -24) = 12, Also, because all nonzero integers divide 0, we have gcd(a, 0) = a ., We stated that two integers a and b are relatively prime if and only if their, only common positive integer factor is 1. This is equivalent to saying that a and b are, relatively prime if gcd(a, b) = 1., 8 and 15 are relatively prime because the positive divisors of 8 are 1, 2, 4, and 8, and, the positive divisors of 15 are 1, 3, 5, and 15. So 1 is the only integer on both lists., , Finding the Greatest Common Divisor, We now describe an algorithm credited to Euclid for easily finding the greatest, common divisor of two integers (Figure 2.2). This algorithm has broad significance, in cryptography. The explanation of the algorithm can be broken down into the following points:, 1. Suppose we wish to determine the greatest common divisor d of the integers, a and b; that is determine d = gcd(a, b). Because gcd( a , b ) = gcd(a, b),, there is no harm in assuming a Ú b 7 0., 2. Dividing a by b and applying the division algorithm, we can state:, a = q1b + r1, , 0 … r1 6 b, , (2.2), , 3. First consider the case in which r1 = 0. Therefore b divides a and clearly no, larger number divides both b and a, because that number would be larger, than b. So we have d = gcd(a, b) = b., 4. The other possibility from Equation (2.2) is r1 ≠ 0. For this case, we can state, that d r1. This is due to the basic properties of divisibility: the relations d a, and d b together imply that d (a - q1b), which is the same as d r1., 5. Before proceeding with the Euclidian algorithm, we need to answer the question: What is the gcd(b, r1)? We know that d b and d r1. Now take any arbitrary integer c that divides both b and r1. Therefore, c (q1b + r1) = a. Because, c divides both a and b, we must have c … d, which is the greatest common, divisor of a and b. Therefore d = gcd(b, r1).
Page 52 :
2.2 / THE EUCLIDEAN ALGORITHM, , 51, , START, , No, , a > b?, , Divide a by b,, calling the, remainder r, , Yes, , Replace, b with r, Same GCD, , No, , r > 0?, , Swap, a and b, , GCD, , Replace, a with b, , GCD, , 710 = 2 × 310 + 90, GCD is, the final, value of b, , 310 = 3 × 90 + 40, , END, , Figure 2.3 Euclidean, Algorithm Example:, gcd(710, 310), , 90 = 2 × 40 + 10, 40 = 4 × 10, , Figure 2.2, , Euclidean Algorithm, , Let us now return to Equation (2.2) and assume that r1 ≠ 0. Because b 7 r1,, we can divide b by r1 and apply the division algorithm to obtain:, b = q2r1 + r2, , 0 … r2 6 r1, , As before, if r2 = 0, then d = r1 and if r2 ≠ 0, then d = gcd(r1, r2). Note that the, remainders form a descending series of nonnegative values and so must terminate, when the remainder is zero. This happens, say, at the (n + 1)th stage where rn - 1 is, divided by rn. The result is the following system of equations:, a = q1b + r1, b = q2r1 + r2, r1 = q3r2 + r3, ~, ~, ~, rn - 2 = qnrn - 1 + rn, rn - 1 = qn + 1rn + 0, d = gcd(a, b) = rn, , 0 6 r1 6, 0 6 r2 6, 0 6 r3 6, ~, ~, ~, 0 6 rn 6, , b, r1, r2, w, , (2.3), , rn - 1, , At each iteration, we have d = gcd(ri, ri + 1) until finally d = gcd(rn, 0) = rn., Thus, we can find the greatest common divisor of two integers by repetitive application of the division algorithm. This scheme is known as the Euclidean algorithm., Figure 2.3 illustrates a simple example., We have essentially argued from the top down that the final result is the, gcd(a, b). We can also argue from the bottom up. The first step is to show that rn, divides a and b. It follows from the last division in Equation (2.3) that rn divides, rn - 1. The next to last division shows that rn divides rn - 2 because it divides both
Page 54 :
2.3 / MODULAR ARITHMETIC, , 53, , 2.3 MODULAR ARITHMETIC, The Modulus, If a is an integer and n is a positive integer, we define a mod n to be the remainder, when a is divided by n. The integer n is called the modulus. Thus, for any integer a,, we can rewrite Equation (2.1) as follows:, a = qn + r, , 0 … r 6 n; q = : a/n ;, , a = : a/n ; * n + (a mod n), 11 mod 7 = 4;, , -11 mod 7 = 3, , Two integers a and b are said to be congruent modulo n, if (a mod n) =, (b mod n). This is written as a K b (mod n).2, 73 K 4 (mod 23);, , 21 K -9 (mod 10), , Note that if a K 0 (mod n), then n a., , Properties of Congruences, Congruences have the following properties:, 1. a K b (mod n) if n (a - b)., 2. a K b (mod n) implies b K a (mod n)., 3. a K b (mod n) and b K c (mod n) imply a K c (mod n)., To demonstrate the first point, if n (a - b), then (a - b) = kn for some k., So we can write a = b + kn. Therefore, (a mod n) = (remainder when b +, kn is divided by n) = (remainder when b is divided by n) = (b mod n)., 23 K 8 (mod 5), -11 K 5 (mod 8), 81 K 0 (mod 27), , because, because, because, , 23 - 8 = 15 = 5 * 3, -11 - 5 = -16 = 8 * ( -2), 81 - 0 = 81 = 27 * 3, , The remaining points are as easily proved., , 2, We have just used the operator mod in two different ways: first as a binary operator that produces a remainder, as in the expression a mod b; second as a congruence relation that shows the equivalence of two, integers, as in the expression a K b (mod n). See Appendix 2A for a discussion.
Page 55 :
54, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , Modular Arithmetic Operations, Note that, by definition (Figure 2.1), the (mod n) operator maps all integers into, the set of integers {0, 1, c , (n - 1)}. This suggests the question: Can we perform, arithmetic operations within the confines of this set? It turns out that we can; this, technique is known as modular arithmetic., Modular arithmetic exhibits the following properties:, 1. [(a mod n) + (b mod n)] mod n = (a + b) mod n, 2. [(a mod n) - (b mod n)] mod n = (a - b) mod n, 3. [(a mod n) * (b mod n)] mod n = (a * b) mod n, We demonstrate the first property. Define (a mod n) = ra and (b mod n) = rb., Then we can write a = ra + jn for some integer j and b = rb + kn for some integer k., Then, (a + b) mod n =, =, =, =, , (ra + jn + rb + kn) mod n, (ra + rb + (k + j)n) mod n, (ra + rb) mod n, [(a mod n) + (b mod n)] mod n, , The remaining properties are proven as easily. Here are examples of the three, properties:, 11 mod 8 = 3; 15 mod 8 = 7, [(11 mod 8) + (15 mod 8)] mod 8 = 10 mod 8 = 2, (11 + 15) mod 8 = 26 mod 8 = 2, [(11 mod 8) - (15 mod 8)] mod 8 = -4 mod 8 = 4, (11 - 15) mod 8 = -4 mod 8 = 4, [(11 mod 8) * (15 mod 8)] mod 8 = 21 mod 8 = 5, (11 * 15) mod 8 = 165 mod 8 = 5, Exponentiation is performed by repeated multiplication, as in ordinary, arithmetic., To find 117 mod 13, we can proceed as follows:, 112 = 121 K 4 (mod 13), 114 = (112)2 K 42 K 3 (mod 13), 117 = 11 * 112 * 114, 117 K 11 * 4 * 3 K 132 K 2 (mod 13), Thus, the rules for ordinary arithmetic involving addition, subtraction, and, multiplication carry over into modular arithmetic.
Page 56 :
2.3 / MODULAR ARITHMETIC, , 55, , Table 2.2 provides an illustration of modular addition and multiplication, modulo 8. Looking at addition, the results are straightforward, and there is a regular pattern to the matrix. Both matrices are symmetric about the main diagonal, in conformance to the commutative property of addition and multiplication. As in, ordinary addition, there is an additive inverse, or negative, to each integer in modular arithmetic. In this case, the negative of an integer x is the integer y such that, (x + y) mod 8 = 0. To find the additive inverse of an integer in the left-hand column, scan across the corresponding row of the matrix to find the value 0; the integer, at the top of that column is the additive inverse; thus, (2 + 6) mod 8 = 0. Similarly,, the entries in the multiplication table are straightforward. In modular arithmetic mod, 8, the multiplicative inverse of x is the integer y such that (x * y) mod 8 = 1 mod 8., Now, to find the multiplicative inverse of an integer from the multiplication table,, scan across the matrix in the row for that integer to find the value 1; the integer at, the top of that column is the multiplicative inverse; thus, (3 * 3) mod 8 = 1. Note, that not all integers mod 8 have a multiplicative inverse; more about that later., , Properties of Modular Arithmetic, Define the set Z n as the set of nonnegative integers less than n:, Z n = {0, 1, c , (n - 1)}, Table 2.2 Arithmetic Modulo 8, +, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 1, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 2, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 1, , 3, , 3, , 4, , 5, , 6, , 7, , 0, , 1, , 2, , 4, , 4, , 5, , 6, , 7, , 0, , 1, , 2, , 3, , 5, , 5, , 6, , 7, , 0, , 1, , 2, , 3, , 4, , 6, , 6, , 7, , 0, , 1, , 2, , 3, , 4, , 5, , 7, , 7, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , (a) Addition modulo 8, *, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , w, , -w, , w -1, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , —, , 1, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 1, , 7, , 1, , 2, , 6, , —, , 2, , 0, , 2, , 4, , 6, , 0, , 2, , 4, , 6, , 3, , 0, , 3, , 6, , 1, , 4, , 7, , 2, , 5, , 3, , 5, , 3, , 4, , —, , 3, , 5, , 4, , 0, , 4, , 0, , 4, , 0, , 4, , 0, , 4, , 4, , 5, , 0, , 5, , 2, , 7, , 4, , 1, , 6, , 3, , 5, , 6, , 0, , 6, , 4, , 2, , 0, , 6, , 4, , 2, , 6, , 2, , —, , 7, , 0, , 7, , 6, , 5, , 4, , 3, , 2, , 1, , 7, , 1, , 7, , (b) Multiplication modulo 8, , Hiva-Network.Com, , (c) Additive and multiplicative, inverse modulo 8
Page 57 :
56, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , This is referred to as the set of residues, or residue classes (mod n). To be more precise, each integer in Z n represents a residue class. We can label the residue classes, (mod n) as [0], [1], [2], c , [n - 1], where, [r] = {a: a is an integer, a K r (mod n)}, The residue classes (mod 4) are, [0] = { c , -16, -12, -8, -4, 0, 4, 8, 12, 16, c }, [1] = { c , -15, -11, -7, -3, 1, 5, 9, 13, 17, c }, [2] = { c , -14, -10, -6, -2, 2, 6, 10, 14, 18, c }, [3] = { c , -13, -9, -5, -1, 3, 7, 11, 15, 19, c }, Of all the integers in a residue class, the smallest nonnegative integer is the, one used to represent the residue class. Finding the smallest nonnegative integer to, which k is congruent modulo n is called reducing k modulo n., If we perform modular arithmetic within Z n, the properties shown in Table 2.3, hold for integers in Z n. We show in the next section that this implies that Z n is a, commutative ring with a multiplicative identity element., There is one peculiarity of modular arithmetic that sets it apart from ordinary, arithmetic. First, observe that (as in ordinary arithmetic) we can write the following:, if (a + b) K (a + c) (mod n) then b K c (mod n), , (2.4), , (5 + 23) K (5 + 7)(mod 8); 23 K 7(mod 8), Equation (2.4) is consistent with the existence of an additive inverse. Adding, the additive inverse of a to both sides of Equation (2.4), we have, (( -a) + a + b) K (( -a) + a + c)(mod n), b K c (mod n), Table 2.3, , Properties of Modular Arithmetic for Integers in Z n, Property, , Expression, , Commutative Laws, , (w + x) mod n = (x + w) mod n, (w * x) mod n = (x * w) mod n, , Associative Laws, , [(w + x) + y] mod n = [w + (x + y)] mod n, [(w * x) * y] mod n = [w * (x * y)] mod n, , Distributive Law, , [w * (x + y)] mod n = [(w * x) + (w * y)] mod n, , Identities, , (0 + w) mod n = w mod n, (1 * w) mod n = w mod n, , Additive Inverse ( - w), , For each w ∈ Z n, there exists a z such that w + z K 0 mod n
Page 58 :
2.3 / MODULAR ARITHMETIC, , 57, , However, the following statement is true only with the attached condition:, if (a * b) K (a * c)(mod n) then b K c(mod n) if a is relatively prime to n, , (2.5), , Recall that two integers are relatively prime if their only common positive integer, factor is 1. Similar to the case of Equation (2.4), we can say that Equation (2.5) is, consistent with the existence of a multiplicative inverse. Applying the multiplicative, inverse of a to both sides of Equation (2.5), we have, ((a-1)ab) K ((a -1)ac)(mod n), b K c(mod n), , To see this, consider an example in which the condition of Equation (2.5) does not, hold. The integers 6 and 8 are not relatively prime, since they have the common, factor 2. We have the following:, 6 * 3 = 18 K 2(mod 8), 6 * 7 = 42 K 2(mod 8), Yet 3 [ 7 (mod 8)., , The reason for this strange result is that for any general modulus n, a multiplier a that is applied in turn to the integers 0 through (n - 1) will fail to produce a, complete set of residues if a and n have any factors in common., , With a = 6 and n = 8,, Z8, Multiply by 6, Residues, , 0, 0, 0, , 1 2, 6 12, 6 4, , 3, 18, 2, , 4, 24, 0, , 5, 30, 6, , 6, 36, 4, , 7, 42, 2, , Because we do not have a complete set of residues when multiplying by, 6, more than one integer in Z 8 maps into the same residue. Specifically,, 6 * 0 mod 8 = 6 * 4 mod 8; 6 * 1 mod 8 = 6 * 5 mod 8; and so on. Because, this is a many-to-one mapping, there is not a unique inverse to the multiply, operation., However, if we take a = 5 and n = 8, whose only common factor is 1,, Z8, Multiply by 5, Residues, , 0, 0, 0, , 1 2, 5 10, 5 2, , 3, 15, 7, , 4, 20, 4, , 5, 25, 1, , 6, 30, 6, , 7, 35, 3, , The line of residues contains all the integers in Z 8, in a different order.
Page 59 :
58, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , In general, an integer has a multiplicative inverse in Z n if and only if that integer is relatively prime to n. Table 2.2c shows that the integers 1, 3, 5, and 7 have a, multiplicative inverse in Z 8; but 2, 4, and 6 do not., , Euclidean Algorithm Revisited, The Euclidean algorithm can be based on the following theorem: For any integers, a, b, with a Ú b Ú 0,, gcd(a, b) = gcd(b, a mod b), , (2.6), , gcd(55, 22) = gcd(22, 55 mod 22) = gcd(22, 11) = 11, To see that Equation (2.6) works, let d = gcd(a, b). Then, by the definition of, gcd, d a and d b. For any positive integer b, we can express a as, a = kb + r K r (mod b), a mod b = r, with k, r integers. Therefore, (a mod b) = a - kb for some integer k. But because, d b, it also divides kb. We also have d a. Therefore, d (a mod b). This shows that, d is a common divisor of b and (a mod b). Conversely, if d is a common divisor of b, and (a mod b), then d kb and thus d [kb + (a mod b)], which is equivalent to d a., Thus, the set of common divisors of a and b is equal to the set of common divisors, of b and (a mod b). Therefore, the gcd of one pair is the same as the gcd of the other, pair, proving the theorem., Equation (2.6) can be used repetitively to determine the greatest common divisor., gcd(18, 12) = gcd(12, 6) = gcd(6, 0) = 6, gcd(11, 10) = gcd(10, 1) = gcd(1, 0) = 1, This is the same scheme shown in Equation (2.3), which can be rewritten in, the following way., Euclidean Algorithm, Calculate, , Which satisfies, , r1 = a mod b, , a = q1b + r1, , r2 = b mod r1, , b = q2r1 + r2, , r3 = r1 mod r2, ~, ~, ~, rn = rn - 2 mod rn - 1, , r1 = q3r2 + r3, ~, ~, ~, rn - 2 = qnrn - 1 + rn, , rn + 1 = rn - 1 mod rn = 0, , rn - 1 = qn + 1rn + 0, d = gcd(a, b) = rn, , We can define the Euclidean algorithm concisely as the following recursive, function.
Page 60 :
2.3 / MODULAR ARITHMETIC, , 59, , Euclid(a,b), if (b=0) then return a;, else return Euclid(b, a mod b);, , The Extended Euclidean Algorithm, We now proceed to look at an extension to the Euclidean algorithm that will be, important for later computations in the area of finite fields and in encryption algorithms, such as RSA. For given integers a and b, the extended Euclidean algorithm, not only calculates the greatest common divisor d but also two additional integers x, and y that satisfy the following equation., ax + by = d = gcd(a, b), , (2.7), , It should be clear that x and y will have opposite signs. Before examining the, algorithm, let us look at some of the values of x and y when a = 42 and b = 30., Note that gcd(42, 30) = 6. Here is a partial table of values3 for 42x + 30y., x, , −3, , −2, , −1, , 0, , 1, , 2, , 3, , y, -3, , -216, , - 174, , -132, , -90, , - 48, , -6, , 36, , -2, , - 186, , - 144, , - 102, , - 60, , -18, , 24, , 66, , -1, , - 156, , - 114, , - 72, , - 30, , 12, , 54, , 96, , 0, , - 126, , - 84, , - 42, , 0, , 42, , 84, , 126, , 1, , - 96, , - 54, , - 12, , 30, , 72, , 114, , 156, , 2, , - 66, , - 24, , 18, , 60, , 102, , 144, , 186, , 3, , - 36, , 6, , 48, , 90, , 132, , 174, , 216, , Observe that all of the entries are divisible by 6. This is not surprising, because both 42 and 30 are divisible by 6, so every number of the form, 42x + 30y = 6(7x + 5y) is a multiple of 6. Note also that gcd(42, 30) = 6 appears, in the table. In general, it can be shown that for given integers a and b, the smallest, positive value of ax + by is equal to gcd(a, b)., Now let us show how to extend the Euclidean algorithm to determine (x, y, d), given a and b. We again go through the sequence of divisions indicated in Equation, (2.3), and we assume that at each step i we can find integers xi and yi that satisfy, ri = axi + byi. We end up with the following sequence., a = q1b + r1, b = q2r1 + r2, r1 = q3r2 + r3, f, rn - 2 = qnrn - 1 + rn, rn - 1 = qn + 1rn + 0, 3, , This example is taken from [SILV06]., , r1 = ax1 +, r2 = ax2 +, r3 = ax3 +, f, rn = axn +, , by1, by2, by3, byn
Page 62 :
2.4 / PRIME NUMBERS, Table 2.4, , 61, , Extended Euclidean Algorithm Example, , i, , ri, , xi, , yi, , -1, , 1759, , qi, , 1, , 0, , 0, , 550, , 0, , 1, , 1, , 109, , 3, , 1, , -3, , 2, , 5, , 5, , -5, , 16, , 3, , 4, , 21, , 106, , - 339, , 4, , 1, , 1, , - 111, , 355, , 5, , 0, , 4, , Result: d = 1; x = - 111; y = 355, , 2.4 PRIME NUMBERS4, A central concern of number theory is the study of prime numbers. Indeed, whole, books have been written on the subject (e.g., [CRAN01], [RIBE96]). In this section,, we provide an overview relevant to the concerns of this book., An integer p 7 1 is a prime number if and only if its only divisors5 are {1 and, {p. Prime numbers play a critical role in number theory and in the techniques discussed in this chapter. Table 2.5 shows the primes less than 2000. Note the way the, primes are distributed. In particular, note the number of primes in each range of, 100 numbers., Any integer a 7 1 can be factored in a unique way as, a = pa11 * pa22 * g * pat t, , (2.9), , where p1 6 p2 6 c 6 pt are prime numbers and where each ai is a positive integer. This is known as the fundamental theorem of arithmetic; a proof can be found, in any text on number theory., 91 = 7 * 13, 3600 = 24 * 32 * 52, 11011 = 7 * 112 * 13, It is useful for what follows to express this another way. If P is the set of, all prime numbers, then any positive integer a can be written uniquely in the, following form:, a = q pap where each ap Ú 0, p∈P, , 4, , In this section, unless otherwise noted, we deal only with the nonnegative integers. The use of negative, integers would introduce no essential differences., 5, Recall from Section 2.1 that integer a is said to be a divisor of integer b if there is no remainder on, division. Equivalently, we say that a divides b.
Page 63 :
229, , 109, , 113, , 127, , 131, , 137, , 139, , 149, , 151, , 157, , 163, , 167, , 173, , 179, , 181, , 191, , 193, , 197, , 199, , 7, , 11, , 13, , 17, , 19, , 23, , 29, , 31, , 37, , 41, , 43, , 47, , 53, , 59, , 61, , 67, , 71, , 73, , 97, , 89, , 83, , 79, , 227, , 107, , 5, , 293, , 283, , 281, , 277, , 271, , 269, , 263, , 257, , 251, , 241, , 239, , 233, , 223, , 103, , 3, , 211, , 101, , 397, , 389, , 383, , 379, , 373, , 367, , 359, , 353, , 349, , 347, , 337, , 331, , 317, , 313, , 311, , 307, , 499, , 491, , 487, , 479, , 467, , 463, , 461, , 457, , 449, , 443, , 439, , 433, , 431, , 421, , 419, , 409, , 401, , Primes Under 2000, , 2, , Table 2.5, , 599, , 593, , 587, , 577, , 571, , 569, , 563, , 557, , 547, , 541, , 523, , 521, , 509, , 503, , 691, , 683, , 677, , 673, , 661, , 659, , 653, , 647, , 643, , 641, , 631, , 619, , 617, , 613, , 607, , 601, , 797, , 787, , 773, , 769, , 761, , 757, , 751, , 743, , 739, , 733, , 727, , 719, , 709, , 701, , 887, , 883, , 881, , 877, , 863, , 859, , 857, , 853, , 839, , 829, , 827, , 823, , 821, , 811, , 809, , 997, , 991, , 983, , 977, , 971, , 967, , 953, , 947, , 941, , 937, , 929, , 919, , 911, , 907, , 1097, , 1093, , 1091, , 1087, , 1069, , 1063, , 1061, , 1051, , 1049, , 1039, , 1033, , 1031, , 1021, , 1019, , 1013, , 1009, , 1193, , 1187, , 1181, , 1171, , 1163, , 1153, , 1151, , 1129, , 1123, , 1117, , 1109, , 1103, , 1297, , 1291, , 1289, , 1283, , 1279, , 1277, , 1259, , 1249, , 1237, , 1231, , 1229, , 1223, , 1217, , 1213, , 1201, , 1399, , 1381, , 1373, , 1367, , 1361, , 1327, , 1321, , 1319, , 1307, , 1303, , 1301, , 1499, , 1493, , 1489, , 1487, , 1483, , 1481, , 1471, , 1459, , 1453, , 1451, , 1447, , 1439, , 1433, , 1429, , 1427, , 1423, , 1409, , 1597, , 1583, , 1579, , 1571, , 1567, , 1559, , 1553, , 1549, , 1543, , 1531, , 1523, , 1511, , 1699, , 1697, , 1693, , 1669, , 1667, , 1663, , 1657, , 1637, , 1627, , 1621, , 1619, , 1613, , 1609, , 1607, , 1601, , 1789, , 1787, , 1783, , 1777, , 1759, , 1753, , 1747, , 1741, , 1733, , 1723, , 1721, , 1709, , 1889, , 1879, , 1877, , 1873, , 1871, , 1867, , 1861, , 1847, , 1831, , 1823, , 1811, , 1801, , 1999, , 1997, , 1993, , 1987, , 1979, , 1973, , 1951, , 1949, , 1933, , 1931, , 1913, , 1907, , 1901, , 62, CHAPTER 2 / INTRODUCTION TO NUMBER THEORY
Page 64 :
2.4 / PRIME NUMBERS, , 63, , The right-hand side is the product over all possible prime numbers p; for any particular value of a, most of the exponents ap will be 0., The value of any given positive integer can be specified by simply listing all the, nonzero exponents in the foregoing formulation., The integer 12 is represented by {a2 = 2, a3 = 1}., The integer 18 is represented by {a2 = 1, a3 = 2}., The integer 91 is represented by {a7 = 1, a13 = 1}., Multiplication of two numbers is equivalent to adding the corresponding, exponents. Given a = q pap, b = q pbp. Define k = ab. We know that the intep∈P, , p∈P, , ger k can be expressed as the product of powers of primes: k = q pkp. It follows, p∈P, that kp = ap + bp for all p ∈ P., k = 12 * 18 = (22 * 3) * (2 * 32) = 216, k2 = 2 + 1 = 3; k3 = 1 + 2 = 3, 216 = 23 * 33 = 8 * 27, , What does it mean, in terms of the prime factors of a and b, to say that a divides b?, Any integer of the form pn can be divided only by an integer that is of a lesser, or equal power of the same prime number, pj with j … n. Thus, we can say the, following., Given, a = q pap, b = q pbp, p∈P, , p∈P, , If a b, then ap … bp for all p., a = 12; b = 36; 12 36, 12 = 22 * 3; 36 = 22 * 32, a2 = 2 = b2, a3 = 1 … 2 = b3, Thus, the inequality ap … bp is satisfied for all prime numbers., , It is easy to determine the greatest common divisor of two positive integers if, we express each integer as the product of primes.
Page 65 :
64, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , 300 = 22 * 31 * 52, 18 = 21 * 32, gcd(18,300) = 21 * 31 * 50 = 6, The following relationship always holds:, If k = gcd(a, b), then kp = min(ap, bp) for all p., Determining the prime factors of a large number is no easy task, so the preceding relationship does not directly lead to a practical method of calculating the, greatest common divisor., , 2.5 FERMAT’S AND EULER’S THEOREMS, Two theorems that play important roles in public-key cryptography are Fermat’s, theorem and Euler’s theorem., , Fermat’s Theorem6, Fermat’s theorem states the following: If p is prime and a is a positive integer not, divisible by p, then, ap - 1 K 1 (mod p), , (2.10), , Proof: Consider the set of positive integers less than p: {1, 2, c , p - 1} and multiply each element by a, modulo p, to get the set X = {a mod p, 2a mod p, c ,, (p - 1)a mod p}. None of the elements of X is equal to zero because p does not, divide a. Furthermore, no two of the integers in X are equal. To see this, assume that, ja K ka(mod p)), where 1 … j 6 k … p - 1. Because a is relatively prime7 to p, we, can eliminate a from both sides of the equation [see Equation (2.3)] resulting in, j K k(mod p). This last equality is impossible, because j and k are both positive integers less than p. Therefore, we know that the (p - 1) elements of X are all positive, integers with no two elements equal. We can conclude the X consists of the set of, integers {1, 2, c , p - 1} in some order. Multiplying the numbers in both sets, (p and X) and taking the result mod p yields, a * 2a * g * (p - 1)a K [(1 * 2 * g * (p - 1)](mod p), ap - 1(p - 1)! K (p - 1)! (mod p), We can cancel the (p - 1)! term because it is relatively prime to p [see Equation, (2.5)]. This yields Equation (2.10), which completes the proof., 6, , This is sometimes referred to as Fermat’s little theorem., Recall from Section 2.2 that two numbers are relatively prime if they have no prime factors in common;, that is, their only common divisor is 1. This is equivalent to saying that two numbers are relatively prime, if their greatest common divisor is 1., 7, , Hiva-Network.Com
Page 66 :
2.5 / FERMAT’S AND EULER’S THEOREMS, , 65, , a = 7, p = 19, 72 = 49 K 11 (mod 19), 74 K 121 K 7 (mod 19), 78 K 49 K 11 (mod 19), 716 K 121 K 7 (mod 19), ap - 1 = 718 = 716 * 72 K 7 * 11 K 1 (mod 19), An alternative form of Fermat’s theorem is also useful: If p is prime and a is a, positive integer, then, ap K a(mod p), , (2.11), , Note that the first form of the theorem [Equation (2.10)] requires that a be relatively prime to p, but this form does not., p = 5, a = 3, p = 5, a = 10, , ap = 35 = 243 K 3(mod 5) = a(mod p), ap = 105 = 100000 K 10(mod 5) K 0(mod 5) = a(mod p), , Euler’s Totient Function, Before presenting Euler’s theorem, we need to introduce an important quantity in, number theory, referred to as Euler’s totient function. This function, written f(n),, is defined as the number of positive integers less than n and relatively prime to n., By convention, f(1) = 1., Determine f(37) and f(35)., Because 37 is prime, all of the positive integers from 1 through 36 are relatively, prime to 37. Thus f(37) = 36., To determine f(35), we list all of the positive integers less than 35 that are, relatively prime to it:, 1, 2, 3, 4, 6, 8, 9, 11, 12, 13, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 31, 32, 33, 34, There are 24 numbers on the list, so f(35) = 24., Table 2.6 lists the first 30 values of f(n). The value f(1) is without meaning, but is defined to have the value 1., It should be clear that, for a prime number p,, f(p) = p - 1, Now suppose that we have two prime numbers p and q with p ≠ q. Then we can, show that, for n = pq,
Page 67 :
66, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, Table 2.6 Some Values of Euler’s Totient Function f(n), n, , f(n), , n, , f(n), , n, , f(n), , 1, , 1, , 11, , 10, , 21, , 12, , 2, , 1, , 12, , 4, , 22, , 10, , 3, , 2, , 13, , 12, , 23, , 22, , 4, , 2, , 14, , 6, , 24, , 8, , 5, , 4, , 15, , 8, , 25, , 20, , 6, , 2, , 16, , 8, , 26, , 12, , 7, , 6, , 17, , 16, , 27, , 18, , 8, , 4, , 18, , 6, , 28, , 12, , 9, , 6, , 19, , 18, , 29, , 28, , 10, , 4, , 20, , 8, , 30, , 8, , f(n) = f(pq) = f(p) * f(q) = (p - 1) * (q - 1), To see that f(n) = f(p) * f(q), consider that the set of positive integers less than, n is the set {1, c , (pq - 1)}. The integers in this set that are not relatively prime, to n are the set {p, 2p, c , (q - 1)p} and the set {q, 2q, c , (p - 1)q}. To see, this, consider that any integer that divides n must divide either of the prime numbers p or q. Therefore, any integer that does not contain either p or q as a factor is, relatively prime to n. Further note that the two sets just listed are non-overlapping:, Because p and q are prime, we can state that none of the integers in the first set can, be written as a multiple of q, and none of the integers in the second set can be written as a multiple of p. Thus the total number of unique integers in the two sets is, (q - 1) + (p - 1). Accordingly,, f(n) =, =, =, =, , (pq - 1) - [(q - 1) + (p - 1)], pq - (p + q) + 1, (p - 1) * (q - 1), f(p) * f(q), , f(21) = f(3) * f(7) = (3 - 1) * (7 - 1) = 2 * 6 = 12, where the 12 integers are {1, 2, 4, 5, 8, 10, 11, 13, 16, 17, 19, 20}., , Euler’s Theorem, Euler’s theorem states that for every a and n that are relatively prime:, af(n) K 1(mod n), , (2.12), , Proof: Equation (2.12) is true if n is prime, because in that case, f(n) = (n - 1), and Fermat’s theorem holds. However, it also holds for any integer n. Recall that
Page 68 :
2.5 / FERMAT’S AND EULER’S THEOREMS, , 67, , f(n) is the number of positive integers less than n that are relatively prime to n., Consider the set of such integers, labeled as, R = {x1, x2, c , xf(n)}, That is, each element xi of R is a unique positive integer less than n with gcd(xi, n) = 1., Now multiply each element by a, modulo n:, S = {(ax1 mod n), (ax2 mod n), c , (axf(n) mod n)}, The set S is a permutation8 of R , by the following line of reasoning:, 1. Because a is relatively prime to n and xi is relatively prime to n, axi must also, be relatively prime to n. Thus, all the members of S are integers that are less, than n and that are relatively prime to n., 2. There are no duplicates in S. Refer to Equation (2.5). If axi mod n = axj, mod n, then xi = xj., Therefore,, f(n), , f(n), , q (axi mod n) = q xi, , i=1, , f(n), , i=1, f(n), , i=1, f(n), , i=1, f(n), , i=1, , i=1, , q axi K q xi (mod n), , af(n) * J q xi R K q xi (mod n), a, , f(n), , K 1 (mod n), , which completes the proof. This is the same line of reasoning applied to the proof, of Fermat’s theorem., a = 3; n = 10; f(10) = 4;, a = 2; n = 11; f(11) = 10;, , af(n) = 34 = 81 = 1(mod 10) = 1(mod n), af(n) = 210 = 1024 = 1(mod 11) = 1(mod n), , As is the case for Fermat’s theorem, an alternative form of the theorem is also, useful:, af(n) + 1 K a(mod n), , (2.13), , Again, similar to the case with Fermat’s theorem, the first form of Euler’s theorem, [Equation (2.12)] requires that a be relatively prime to n, but this form does not., , 8, A permutation of a finite set of elements S is an ordered sequence of all the elements of S, with each, element appearing exactly once.
Page 69 :
68, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , 2.6 TESTING FOR PRIMALITY, For many cryptographic algorithms, it is necessary to select one or more very large, prime numbers at random. Thus, we are faced with the task of determining whether, a given large number is prime. There is no simple yet efficient means of accomplishing this task., In this section, we present one attractive and popular algorithm. You may be, surprised to learn that this algorithm yields a number that is not necessarily a prime., However, the algorithm can yield a number that is almost certainly a prime. This will, be explained presently. We also make reference to a deterministic algorithm for finding primes. The section closes with a discussion concerning the distribution of primes., , Miller–Rabin Algorithm9, The algorithm due to Miller and Rabin [MILL75, RABI80] is typically used to test, a large number for primality. Before explaining the algorithm, we need some background. First, any positive odd integer n Ú 3 can be expressed as, n - 1 = 2kq, , with k 7 0, q odd, , To see this, note that n - 1 is an even integer. Then, divide (n - 1) by 2 until the, result is an odd number q, for a total of k divisions. If n is expressed as a binary, number, then the result is achieved by shifting the number to the right until the, rightmost digit is a 1, for a total of k shifts. We now develop two properties of prime, numbers that we will need., TWO PROPERTIES OF PRIME NUMBERS The first property is stated as follows: If p is, prime and a is a positive integer less than p, then a2 mod p = 1 if and only if either, a mod p = 1 or a mod p = -1 mod p = p - 1. By the rules of modular arithmetic, (a mod p) (a mod p) = a2 mod p. Thus, if either a mod p = 1 or a mod p = -1,, then a2 mod p = 1. Conversely, if a2 mod p = 1, then (a mod p)2 = 1, which is true, only for a mod p = 1 or a mod p = -1., The second property is stated as follows: Let p be a prime number greater, than 2. We can then write p - 1 = 2kq with k 7 0, q odd. Let a be any integer in, the range 1 6 a 6 p - 1. Then one of the two following conditions is true., 1. aq is congruent to 1 modulo p. That is, aq mod p = 1, or equivalently,, aq K 1(mod p)., k-1, 2. One of the numbers aq, a2q, a4q, c , a2 q is congruent to -1 modulo p. That is, there is some number j in the range (1 … j … k) such that, j-1, j-1, a2 q mod p = -1 mod p = p - 1 or equivalently, a2 q K - 1(mod p)., , Proof: Fermat’s theorem [Equation (2.10)] states that an - 1 K 1(mod, n) if n is, k, prime. We have p - 1 = 2kq. Thus, we know that ap - 1 mod p = a2 q mod p = 1., Thus, if we look at the sequence of numbers, aq mod p, a2q mod p, a4q mod p, c , a2, 9, , k-1, , q, , k, , mod p, a2 q mod p, , (2.14), , Also referred to in the literature as the Rabin-Miller algorithm, or the Rabin-Miller test, or the Miller–, Rabin test.
Page 70 :
2.6 / TESTING FOR PRIMALITY, , 69, , we know that the last number in the list has value 1. Further, each number in the list, is the square of the previous number. Therefore, one of the following possibilities, must be true., 1. The first number on the list, and therefore all subsequent numbers on the list,, equals 1., 2. Some number on the list does not equal 1, but its square mod p does equal 1., By virtue of the first property of prime numbers defined above, we know that, the only number that satisfies this condition is p - 1. So, in this case, the list, contains an element equal to p - 1., This completes the proof., DETAILS OF THE ALGORITHM These considerations lead to the conclusion that,, if n is prime, then either the first element in the list of residues, or remainders,, k-1, k, (aq, a2q, c , a2 q, a2 q) modulo n equals 1; or some element in the list equals, (n - 1); otherwise n is composite (i.e., not a prime). On the other hand, if the, condition is met, that does not necessarily mean that n is prime. For example, if, n = 2047 = 23 * 89, then n - 1 = 2 * 1023. We compute 21023 mod 2047 = 1, so, that 2047 meets the condition but is not prime., We can use the preceding property to devise a test for primality. The procedure, TEST takes a candidate integer n as input and returns the result composite if n is, definitely not a prime, and the result inconclusive if n may or may not be a prime., TEST (n), 1. Find integers k, q, with k > 0, q odd, so that, (n − 1 = 2k q);, 2. Select a random integer a, 1 < a < n - 1;, 3. if aq mod n = 1 then return(”inconclusive”);, 4. for j = 0 to k - 1 do, j, 5., if a2 qmod n = n - 1 then return(”inconclusive”);, 6. return(”composite”);, Let us apply the test to the prime number n = 29. We have (n - 1) = 28 =, 22(7) = 2kq. First, let us try a = 10. We compute 107 mod 29 = 17, which is neither, 1 nor 28, so we continue the test. The next calculation finds that (107)2 mod 29 = 28,, and the test returns inconclusive (i.e., 29 may be prime). Let’s try again with, a = 2. We have the following calculations: 27 mod 29 = 12; 214 mod 29 = 28; and, the test again returns inconclusive. If we perform the test for all integers a in, the range 1 through 28, we get the same inconclusive result, which is compatible, with n being a prime number., Now let us apply the test to the composite number n = 13 * 17 = 221. Then, (n - 1) = 220 = 22(55) = 2kq. Let us try a = 5. Then we have 555 mod 221 = 112,, which is neither 1 nor 220(555)2 mod 221 = 168. Because we have used all values of j, (i.e., j = 0 and j = 1) in line 4 of the TEST algorithm, the test returns composite, indicating that 221 is definitely a composite number. But suppose we had selected a = 21., Then we have 2155 mod 221 = 200; (2155)2 mod 221 = 220; and the test returns, inconclusive, indicating that 221 may be prime. In fact, of the 218 integers from 2, through 219, four of these will return an inconclusive result, namely 21, 47, 174, and 200.
Page 71 :
70, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , REPEATED USE OF THE MILLER–RABIN ALGORITHM How can we use the Miller–Rabin, algorithm to determine with a high degree of confidence whether or not an integer, is prime? It can be shown [KNUT98] that given an odd number n that is not prime, and a randomly chosen integer, a with 1 6 a 6 n - 1, the probability that TEST, will return inconclusive (i.e., fail to detect that n is not prime) is less than 1/4., Thus, if t different values of a are chosen, the probability that all of them will pass, TEST (return inconclusive) for n is less than (1/4)t. For example, for t = 10, the, probability that a nonprime number will pass all ten tests is less than 10-6. Thus,, for a sufficiently large value of t , we can be confident that n is prime if Miller’s test, always returns inconclusive., This gives us a basis for determining whether an odd integer n is prime with, a reasonable degree of confidence. The procedure is as follows: Repeatedly invoke, TEST (n) using randomly chosen values for a. If, at any point, TEST returns, composite, then n is determined to be nonprime. If TEST continues to return, inconclusive for t tests, then for a sufficiently large value of t, assume that n, is prime., , A Deterministic Primality Algorithm, Prior to 2002, there was no known method of efficiently proving the primality of, very large numbers. All of the algorithms in use, including the most popular (Miller–, Rabin), produced a probabilistic result. In 2002 (announced in 2002, published, in 2004), Agrawal, Kayal, and Saxena [AGRA04] developed a relatively simple, deterministic algorithm that efficiently determines whether a given large number, is a prime. The algorithm, known as the AKS algorithm, does not appear to be as, efficient as the Miller–Rabin algorithm. Thus far, it has not supplanted this older,, probabilistic technique., , Distribution of Primes, It is worth noting how many numbers are likely to be rejected before a prime number is found using the Miller–Rabin test, or any other test for primality. A result, from number theory, known as the prime number theorem, states that the primes, near n are spaced on the average one every ln (n) integers. Thus, on average, one, would have to test on the order of ln(n) integers before a prime is found. Because, all even integers can be immediately rejected, the correct figure is 0.5 ln(n). For, example, if a prime on the order of magnitude of 2200 were sought, then about, 0.5 ln(2200) = 69 trials would be needed to find a prime. However, this figure is just, an average. In some places along the number line, primes are closely packed, and in, other places there are large gaps., , The two consecutive odd integers 1,000,000,000,061 and 1,000,000,000,063, are both prime. On the other hand, 1001! + 2, 1001! + 3, c , 1001! + 1000,, 1001! + 1001 is a sequence of 1000 consecutive composite integers.
Page 72 :
2.7 / THE CHINESE REMAINDER THEOREM, , 71, , 2.7 THE CHINESE REMAINDER THEOREM, One of the most useful results of number theory is the Chinese remainder theorem, (CRT).10 In essence, the CRT says it is possible to reconstruct integers in a certain, range from their residues modulo a set of pairwise relatively prime moduli., , The 10 integers in Z 10, that is the integers 0 through 9, can be reconstructed from, their two residues modulo 2 and 5 (the relatively prime factors of 10). Say the, known residues of a decimal digit x are r2 = 0 and r5 = 3; that is, x mod 2 = 0, and x mod 5 = 3. Therefore, x is an even integer in Z 10 whose remainder, on division by 5, is 3. The unique solution is x = 8., , The CRT can be stated in several ways. We present here a formulation that is most, useful from the point of view of this text. An alternative formulation is explored in, Problem 2.33. Let, k, , M = q mi, i=1, , where the mi are pairwise relatively prime; that is, gcd(mi, mj) = 1 for 1 … i, j … k,, and i ≠ j. We can represent any integer A in Z M by a k-tuple whose elements are in, Z mi using the following correspondence:, A 4 (a1, a2, c , ak), , (2.15), , where A ∈ Z M, ai ∈ Z mi, and ai = A mod mi for 1 … i … k. The CRT makes two, assertions., 1. The mapping of Equation (2.15) is a one-to-one correspondence (called a, bijection) between Z M and the Cartesian product Z m1 * Z m2 * c * Z mk., That is, for every integer A such that 0 … A 6 M, there is a unique k-tuple, (a1, a2, c , ak) with 0 … ai 6 mi that represents it, and for every such, k-tuple (a1, a2, c , ak), there is a unique integer A in Z M., 2. Operations performed on the elements of Z M can be equivalently performed, on the corresponding k-tuples by performing the operation independently in, each coordinate position in the appropriate system., Let us demonstrate the first assertion. The transformation from A to, (a1, a2, c , ak), is obviously unique; that is, each ai is uniquely calculated as, ai = A mod mi. Computing A from (a1, a2, c , ak) can be done as follows. Let, , 10, , The CRT is so called because it is believed to have been discovered by the Chinese mathematician, Sun-Tsu in around 100 A.D.
Page 73 :
72, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , Mi = M/mi for 1 … i … k. Note that Mi = m1 * m2 * c * mi - 1 * mi + 1 * c, * mk, so that Mi K 0 (mod mj) for all j ≠ i. Then let, ci = Mi * (Mi-1 mod mi), , for 1 … i … k, , (2.16), , By the definition of Mi, it is relatively prime to mi and therefore has a unique multiplicative inverse mod mi. So Equation (2.16) is well defined and produces a unique, value ci. We can now compute, k, , A K ¢ a aici ≤(mod M), i=1, , (2.17), , To show that the value of A produced by Equation (2.17) is correct, we must, show that ai = A mod mi for 1 … i … k. Note that cj K Mj K 0 (mod mi) if j ≠ i,, and that ci K 1 (mod mi). It follows that ai = A mod mi., The second assertion of the CRT, concerning arithmetic operations, follows, from the rules for modular arithmetic. That is, the second assertion can be stated as, follows: If, A 4 (a1, a2, c , ak), B 4 (b1, b2, c , bk), then, (A + B) mod M 4 ((a1 + b1) mod m1, c , (ak + bk) mod mk), (A - B) mod M 4 ((a1 - b1) mod m1, c , (ak - bk) mod mk), (A * B) mod M 4 ((a1 * b1) mod m1, c , (ak * bk) mod mk), One of the useful features of the Chinese remainder theorem is that it provides, a way to manipulate (potentially very large) numbers mod M in terms of tuples of, smaller numbers. This can be useful when M is 150 digits or more. However, note, that it is necessary to know beforehand the factorization of M., , To represent 973 mod 1813 as a pair of numbers mod 37 and 49, define, m1, m2, M, A, , =, =, =, =, , 37, 49, 1813, 973, , We also have M1 = 49 and M2 = 37. Using the extended Euclidean algorithm,, we compute M1-1 = 34 mod m1 and M2-1 = 4 mod m2. (Note that we only need, to compute each Mi and each Mi-1 once.) Taking residues modulo 37 and 49, our, representation of 973 is (11, 42), because 973 mod 37 = 11 and 973 mod 49 = 42., Now suppose we want to add 678 to 973. What do we do to (11, 42)? First, we compute (678) 4 (678 mod 37, 678 mod 49) = (12, 41). Then we add the, tuples element-wise and reduce (11 + 12 mod 37, 42 + 41 mod 49) = (23, 34)., To verify that this has the correct effect, we compute
Page 74 :
2.8 / DISCRETE LOGARITHMS, , 73, , (23, 34) 4 a1M1M1-1 + a2M2M2-1 mod M, = [(23)(49)(34) + (34)(37)(4)] mod 1813, = 43350 mod 1813, = 1651, and check that it is equal to (973 + 678) mod 1813 = 1651. Remember that in, the above derivation, Mi-1 is the multiplicative inverse of M1 modulo m1 and M2-1, is the multiplicative inverse of M2 modulo m2., Suppose we want to multiply 1651 (mod 1813) by 73. We multiply (23, 34), by 73 and reduce to get (23 * 73 mod 37, 34 * 73 mod 49) = (14, 32). It is easily verified that, (14, 32) 4 [(14)(49)(34) + (32)(37)(4)] mod 1813, = 865, = 1651 * 73 mod 1813, , 2.8 DISCRETE LOGARITHMS, Discrete logarithms are fundamental to a number of public-key algorithms, including Diffie–Hellman key exchange and the digital signature algorithm (DSA). This, section provides a brief overview of discrete logarithms. For the interested reader,, more detailed developments of this topic can be found in [ORE67] and [LEVE90]., , The Powers of an Integer, Modulo n, Recall from Euler’s theorem [Equation (2.12)] that, for every a and n that are relatively prime,, af(n) K 1 (mod n), where f(n), Euler’s totient function, is the number of positive integers less than n, and relatively prime to n. Now consider the more general expression:, am K 1 (mod n), , (2.18), , If a and n are relatively prime, then there is at least one integer m that satisfies, Equation (2.18), namely, m = f(n). The least positive exponent m for which, Equation (2.18) holds is referred to in several ways:, ■, ■, ■, , The order of a (mod n), The exponent to which a belongs (mod n), The length of the period generated by a, , Hiva-Network.Com
Page 75 :
74, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , To see this last point, consider the powers of 7, modulo 19:, 71, 72, 73, 74, 75, , K, =, =, =, =, , 49 = 2 * 19 + 11, 343 = 18 * 19 + 1, 2401 = 126 * 19 + 7, 16807 = 884 * 19 + 11, , K, K, K, K, , 7 (mod 19), 11 (mod 19), 1 (mod 19), 7 (mod 19), 11 (mod 19), , There is no point in continuing because the sequence is repeating. This can be, proven by noting that 73 K 1(mod 19), and therefore, 73 + j K 737j K 7j(mod 19),, and hence, any two powers of 7 whose exponents differ by 3 (or a multiple of 3), are congruent to each other (mod 19). In other words, the sequence is periodic,, and the length of the period is the smallest positive exponent m such that, 7m K 1(mod 19)., , Table 2.7 shows all the powers of a, modulo 19 for all positive a 6 19. The, length of the sequence for each base value is indicated by shading. Note the, following:, 1. All sequences end in 1. This is consistent with the reasoning of the preceding, few paragraphs., 2. The length of a sequence divides f(19) = 18. That is, an integral number of, sequences occur in each row of the table., 3. Some of the sequences are of length 18. In this case, it is said that the base integer a generates (via powers) the set of nonzero integers modulo 19. Each such, integer is called a primitive root of the modulus 19., More generally, we can say that the highest possible exponent to which a number can belong (mod n) is f(n). If a number is of this order, it is referred to as a, primitive root of n. The importance of this notion is that if a is a primitive root of n,, then its powers, a, a2, c , af(n), are distinct (mod n) and are all relatively prime to n. In particular, for a prime number p, if a is a primitive root of p, then, a, a2, c , ap - 1, are distinct (mod p). For the prime number 19, its primitive roots are 2, 3, 10, 13, 14,, and 15., Not all integers have primitive roots. In fact, the only integers with primitive, roots are those of the form 2, 4, pa, and 2pa, where p is any odd prime and a is a, positive integer. The proof is not simple but can be found in many number theory, books, including [ORE76].
Page 76 :
2.8 / DISCRETE LOGARITHMS, Table 2.7, , 75, , Powers of Integers, Modulo 19, , a, , a2, , a3, , a4, , a5, , a6, , a7, , a8, , a9, , a10, , a11, , a12, , a13, , a14, , a15, , a16, , a17, , a18, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 1, , 2, , 4, , 8, , 16, , 13, , 7, , 14, , 9, , 18, , 17, , 15, , 11, , 3, , 6, , 12, , 5, , 10, , 1, , 3, , 9, , 8, , 5, , 15, , 7, , 2, , 6, , 18, , 16, , 10, , 11, , 14, , 4, , 12, , 17, , 13, , 1, , 4, , 16, , 7, , 9, , 17, , 11, , 6, , 5, , 1, , 4, , 16, , 7, , 9, , 17, , 11, , 6, , 5, , 1, , 5, , 6, , 11, , 17, , 9, , 7, , 16, , 4, , 1, , 5, , 6, , 11, , 17, , 9, , 7, , 16, , 4, , 1, , 6, , 17, , 7, , 4, , 5, , 11, , 9, , 16, , 1, , 6, , 17, , 7, , 4, , 5, , 11, , 9, , 16, , 1, , 7, , 11, , 1, , 7, , 11, , 1, , 7, , 11, , 1, , 7, , 11, , 1, , 7, , 11, , 1, , 7, , 11, , 1, , 8, , 7, , 18, , 11, , 12, , 1, , 8, , 7, , 18, , 11, , 12, , 1, , 8, , 7, , 18, , 11, , 12, , 1, , 9, , 5, , 7, , 6, , 16, , 11, , 4, , 17, , 1, , 9, , 5, , 7, , 6, , 16, , 11, , 4, , 17, , 1, , 10, , 5, , 12, , 6, , 3, , 11, , 15, , 17, , 18, , 9, , 14, , 7, , 13, , 16, , 8, , 4, , 2, , 1, , 11, , 7, , 1, , 11, , 7, , 1, , 11, , 7, , 1, , 11, , 7, , 1, , 11, , 7, , 1, , 11, , 7, , 1, , 12, , 11, , 18, , 7, , 8, , 1, , 12, , 11, , 18, , 7, , 8, , 1, , 12, , 11, , 18, , 7, , 8, , 1, , 13, , 17, , 12, , 4, , 14, , 11, , 10, , 16, , 18, , 6, , 2, , 7, , 15, , 5, , 8, , 9, , 3, , 1, , 14, , 6, , 8, , 17, , 10, , 7, , 3, , 4, , 18, , 5, , 13, , 11, , 2, , 9, , 12, , 16, , 15, , 1, , 15, , 16, , 12, , 9, , 2, , 11, , 13, , 5, , 18, , 4, , 3, , 7, , 10, , 17, , 8, , 6, , 14, , 1, , 16, , 9, , 11, , 5, , 4, , 7, , 17, , 6, , 1, , 16, , 9, , 11, , 5, , 4, , 7, , 17, , 6, , 1, , 17, , 4, , 11, , 16, , 6, , 7, , 5, , 9, , 1, , 17, , 4, , 11, , 16, , 6, , 7, , 5, , 9, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , 18, , 1, , Logarithms for Modular Arithmetic, With ordinary positive real numbers, the logarithm function is the inverse of exponentiation. An analogous function exists for modular arithmetic., Let us briefly review the properties of ordinary logarithms. The logarithm of a, number is defined to be the power to which some positive base (except 1) must be, raised in order to equal the number. That is, for base x and for a value y,, y = xlogx(y), The properties of logarithms include, log x(1) = 0, log x(x) = 1, log x(yz) = logx(y) + log x(z), , (2.19), , log x(yr) = r * log x(y), , (2.20), , Consider a primitive root a for some prime number p (the argument can, be developed for nonprimes as well). Then we know that the powers of a from
Page 77 :
76, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , 1 through (p - 1) produce each integer from 1 through (p - 1) exactly once. We, also know that any integer b satisfies, b K r (mod p) for some r, where 0 … r … (p - 1), by the definition of modular arithmetic. It follows that for any integer b and a primitive root a of prime number p, we can find a unique exponent i such that, b K ai(mod p) where 0 … i … (p - 1), This exponent i is referred to as the discrete logarithm of the number b for the base, a (mod p). We denote this value as dlog a,p(b).11, Note the following:, dlog a,p(1) = 0 because a0 mod p = 1 mod p = 1, , (2.21), , dlog a,p(a) = 1 because a1 mod p = a, , (2.22), , Here is an example using a nonprime modulus, n = 9. Here f(n) = 6 and a = 2, is a primitive root. We compute the various powers of a and find, 20, 21, 22, 23, , =, =, =, =, , 1, 2, 4, 8, , 24 K 7 (mod 9), 25 K 5 (mod 9), 26 K 1 (mod 9), , This gives us the following table of the numbers with given discrete logarithms, (mod 9) for the root a = 2:, Logarithm, Number, , 0, 1, , 1, 2, , 2, 4, , 3, 8, , 4, 7, , 5, 5, , To make it easy to obtain the discrete logarithms of a given number, we rearrange, the table:, Number, Logarithm, , 1, 0, , 2, 1, , 4, 2, , 5, 5, , 7, 4, , 8, 3, , Now consider, x = adloga, p(x) mod p, xy = adloga, p(xy) mod p, , 11, , y = adloga, p(y) mod p, , Many texts refer to the discrete logarithm as the index. There is no generally agreed notation for this, concept, much less an agreed name.
Page 78 :
2.8 / DISCRETE LOGARITHMS, , 77, , Using the rules of modular multiplication,, xy mod p = [(x mod p)(y mod p)] mod p, adloga, p(xy) mod p = [(adloga, p(x) mod p)(adloga, p(y) mod p)] mod p, = (adloga, p(x) + dloga, p(y)) mod p, But now consider Euler’s theorem, which states that, for every a and n that are, relatively prime,, af(n) K 1(mod n), Any positive integer z can be expressed in the form z = q + kf(n), with, 0 … q 6 f(n). Therefore, by Euler’s theorem,, az K aq(mod n), , if z K q mod f(n), , Applying this to the foregoing equality, we have, dlog a, p(xy) K [dlog a, p(x) + dlog a, p(y)](mod f(p)), and generalizing,, dlog a, p(yr) K [r * dlog a, p(y)](mod f(p)), This demonstrates the analogy between true logarithms and discrete logarithms., Keep in mind that unique discrete logarithms mod m to some base a exist only, if a is a primitive root of m., Table 2.8, which is directly derived from Table 2.7, shows the sets of discrete, logarithms that can be defined for modulus 19., , Calculation of Discrete Logarithms, Consider the equation, y = gx mod p, Given g, x, and p, it is a straightforward matter to calculate y. At the worst, we must, perform x repeated multiplications, and algorithms exist for achieving greater efficiency (see Chapter 9)., However, given y, g, and p, it is, in general, very difficult to calculate x (take, the discrete logarithm). The difficulty seems to be on the same order of magnitude, as that of factoring primes required for RSA. At the time of this writing, the asymptotically fastest known algorithm for taking discrete logarithms modulo a prime, number is on the order of [BETH91]:, e ((ln p), which is not feasible for large primes., , 1/3, , (ln(ln p))2/3)
Page 79 :
78, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , Table 2.8 Tables of Discrete Logarithms, Modulo 19, (a) Discrete logarithms to the base 2, modulo 19, a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log2,19(a), , 18, , 1, , 13, , 2, , 16, , 14, , 6, , 3, , 8, , 17, , 12, , 15, , 5, , 7, , 11, , 4, , 10, , 9, , a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log3,19(a), , 18, , 7, , 1, , 14, , 4, , 8, , 6, , 3, , 2, , 11, , 12, , 15, , 17, , 13, , 5, , 10, , 16, , 9, , (b) Discrete logarithms to the base 3, modulo 19, , (c) Discrete logarithms to the base 10, modulo 19, a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log10,19(a) 18, , 17, , 5, , 16, , 2, , 4, , 12, , 15, , 10, , 1, , 6, , 3, , 13, , 11, , 7, , 14, , 8, , 9, , a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log13,19(a) 18, , 11, , 17, , 4, , 14, , 10, , 12, , 15, , 16, , 7, , 6, , 3, , 1, , 5, , 13, , 8, , 2, , 9, , (d) Discrete logarithms to the base 13, modulo 19, , (e) Discrete logarithms to the base 14, modulo 19, a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log14,19(a) 18, , 13, , 7, , 8, , 10, , 2, , 6, , 3, , 14, , 5, , 12, , 15, , 11, , 1, , 17, , 16, , 4, , 9, , a, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , 13, , 14, , 15, , 16, , 17, , 18, , log15,19(a) 18, , 5, , 11, , 10, , 8, , 16, , 12, , 15, , 4, , 13, , 6, , 3, , 7, , 17, , 1, , 2, , 14, , 9, , (f) Discrete logarithms to the base 15, modulo 19, , 2.9 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, bijection, composite number, commutative, Chinese remainder theorem, discrete logarithm, divisor, Euclidean algorithm, , Euler’s theorem, Euler’s totient function, Fermat’s theorem, greatest common divisor, identity element, index, modular arithmetic, , modulus, order, prime number, primitive root, relatively prime, residue
Page 80 :
2.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 79, , Review Questions, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, , What does it mean to say that b is a divisor of a?, What is the meaning of the expression a divides b?, What is the difference between modular arithmetic and ordinary arithmetic?, What is a prime number?, What is Euler’s totient function?, The Miller–Rabin test can determine if a number is not prime but cannot determine, if a number is prime. How can such an algorithm be used to test for primality?, What is a primitive root of a number?, What is the difference between an index and a discrete logarithm?, , Problems, 2.1, 2.2, 2.3, , 2.4, , 2.5, , 2.6, , 2.7, 2.8, , 2.9, , 2.10, 2.11, , Reformulate Equation (2.1), removing the restriction that a is a nonnegative integer., That is, let a be any integer., Draw a figure similar to Figure 2.1 for a 6 0., For each of the following equations, find an integer x that satisfies the equation., a. 4 x K 2 (m od 3 ), b. 7 x K 4 (m od 9 ), c. 5 x K 3 (m od 1 1 ), In this text, we assume that the modulus is a positive integer. But the definition of the, expression a mod n also makes perfect sense if n is negative. Determine the following:, a. 7 mod 4, b. 7 mod - 4, c. - 7 mod 4, d. - 7 m od - 4, A modulus of 0 does not fit the definition but is defined by convention as follows:, a mod 0 = a. With this definition in mind, what does the following expression mean:, a K b (mod 0)?, In Section 2.3, we define the congruence relationship as follows: Two integers a and, b are said to be congruent modulo n if (a mod n) = (b mod n). We then proved that, a K b (mod n) if n (a - b). Some texts on number theory use this latter relationship as the definition of congruence: Two integers a and b are said to be congruent, modulo n if n (a - b). Using this latter definition as the starting point, prove that, if, (a mod n) = (b mod n), then n divides (a - b)., What is the smallest positive integer that has exactly k divisors? Provide answers for, values for 1 … k … 8., Prove the following:, a. a K b (mod n) implies b K a (mod n), b. a K b (mod n) and b K c (mod n) imply a K c (mod n), Prove the following:, a. [(a mod n) - (b mod n)] mod n = (a - b) mod n, b. [(a mod n) * (b mod n)] mod n = (a * b) mod n, Find the multiplicative inverse of each nonzero element in Z 5., Show that an integer N is congruent modulo 9 to the sum of its decimal digits. For, example, 7 2 3 K 7 + 2 + 3 K 1 2 K 1 + 2 K 3 (m od 9 ). This is the basis for the, familiar procedure of “casting out 9’s” when checking computations in arithmetic.
Page 81 :
80, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, 2.12, 2.13, , a. Determine gcd(72345, 43215), b. Determine gcd(3486, 10292), The purpose of this problem is to set an upper bound on the number of iterations of, the Euclidean algorithm., a. Suppose that m = qn + r with q 7 0 and 0 … r 6 n. Show that m/2 7 r., b. Let Ai be the value of A in the Euclidean algorithm after the ith iteration. Show that, Ai + 2 6, , 2.14, , 2.15, , Ai, 2, , c. Show that if m, n, and N are integers with (1 … m, n, … 2N), then the Euclidean, algorithm takes at most 2N steps to find gcd(m, n)., The Euclidean algorithm has been known for over 2000 years and has always been, a favorite among number theorists. After these many years, there is now a potential, competitor, invented by J. Stein in 1961. Stein’s algorithms is as follows: Determine, gcd(A, B) with A, B Ú 1., STEP 1 Set A1 = A, B1 = B, C1 = 1, STEP 2 For n > 1, (1) If An = Bn, stop. gcd(A, B) = AnCn, (2) If An and Bn are both even, set An + 1 = An/2, Bn + 1 = Bn/2,, Cn + 1 = 2Cn, (3) If An is even and Bn is odd, set An + 1 = An/2, Bn + 1 = Bn,, Cn + 1 = Cn, (4) If An is odd and Bn is even, set An + 1 = An, Bn + 1 = Bn/2,, Cn + 1 = Cn, (5) If An and Bn are both odd, set An + 1 = An - Bn , Bn + 1 =, min (Bn, An), Cn + 1 = Cn, Continue to step n + 1., a. To get a feel for the two algorithms, compute gcd(6150, 704) using both the Euclidean and Stein’s algorithm., b. What is the apparent advantage of Stein’s algorithm over the Euclidean algorithm?, a. Show that if Stein’s algorithm does not stop before the nth step, then, Cn + 1 * gcd(An + 1, Bn + 1) = Cn * gcd(An, Bn), b. Show that if the algorithm does not stop before step (n - 1), then, An + 2Bn + 2 …, , 2.16, , 2.17, , AnBn, 2, , c. Show that if 1 … A, B … 2N, then Stein’s algorithm takes at most 4N steps to find, gcd(m, n). Thus, Stein’s algorithm works in roughly the same number of steps as, the Euclidean algorithm., d. Demonstrate that Stein’s algorithm does indeed return gcd(A, B)., Using the extended Euclidean algorithm, find the multiplicative inverse of, a. 135 mod 61, b. 7465 mod 2464, c. 42828 mod 6407, The purpose of this problem is to determine how many prime numbers there, are. Suppose there are a total of n prime numbers, and we list these in order:, p1 = 2 6 p2 = 3 6 p3 = 5 6 c 6 pn., a. Define X = 1 + p1p2 c pn. That is, X is equal to one plus the product of all the, primes. Can we find a prime number Pm that divides X?, b. What can you say about m?, c. Deduce that the total number of primes cannot be finite., d. Show that Pn + 1 … 1 + p1p2 c pn.
Page 82 :
2.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 2.18, , 81, , The purpose of this problem is to demonstrate that the probability that two random, numbers are relatively prime is about 0.6., a. Let P = Pr[gcd(a, b) = 1]. Show that P = Pr[gcd(a, b) = d] = P/d 2. Hint:, a b, Consider the quantity gcd a , b., d d, b. The sum of the result of part (a) over all possible values of d is 1. That is, Σ d Ú 1Pr[gcd(a, b) = d] = 1. Use this equality to determine the value of P. Hint:, ∞, 1, p2, Use the identity a 2 =, ., 6, i=1 i, , 2.19, 2.20, 2.21, 2.22, 2.23, , 2.24, 2.25, 2.26, 2.27, , 2.28, , Why is gcd(n, n + 1) = 1 for two consecutive integers n and n + 1?, Using Fermat’s theorem, find 4 2 2 5 mod 13., Use Fermat’s theorem to find a number a between 0 and 92 with a congruent to 71013, modulo 93., Use Fermat’s theorem to find a number x between 0 and 37 with x 7 3 congruent to 4, modulo 37. (You should not need to use any brute-force searching.), Use Euler’s theorem to find a number a between 0 and 9 such that a is congruent to, 9 1 0 1 modulo 10. (Note: This is the same as the last digit of the decimal expansion of, 9 1 0 0 .), Use Euler’s theorem to find a number x between 0 and 14 with x 6 1 congruent to 7, modulo 15. (You should not need to use any brute-force searching.), Notice in Table 2.6 that f(n) is even for n 7 2. This is true for all n 7 2. Give a concise argument why this is so., Prove the following: If p is prime, then f(pi) = pi - pi - 1. Hint: What numbers have, a factor in common with pi?, It can be shown (see any book on number theory) that if gcd(m, n) = 1 then, f(mn) = f(m)f(n). Using this property, the property developed in the preceding, problem, and the property that f(p) = p - 1 for p prime, it is straightforward to, determine the value of f(n) for any n. Determine the following:, a. f(29), b. f(51), c. f(455), d. f(616), It can also be shown that for arbitrary positive integer a, f(a) is given by, t, , f(a) = q [pai i - 1(pi - 1)], i=1, , 2.29, 2.30, , where a is given by Equation (2.9), namely: a = Pa11Pa22 c Pat t. Demonstrate this result., Consider the function: f(n) = number of elements in the set {a: 0 … a 6 n and, gcd(a, n) = 1}. What is this function?, Although ancient Chinese mathematicians did good work coming up with their, remainder theorem, they did not always get it right. They had a test for primality. The, test said that n is prime if and only if n divides (2n - 2)., a. Give an example that satisfies the condition using an odd prime., b. The condition is obviously true for n = 2. Prove that the condition is true if n is an, odd prime (proving the if condition)., c. Give an example of an odd n that is not prime and that does not satisfy the condition. You can do this with nonprime numbers up to a very large value. This misled, the Chinese mathematicians into thinking that if the condition is true then n is prime., d. Unfortunately, the ancient Chinese never tried n = 341, which is nonprime, (341 = 11 * 31), yet 341 divides 2341 - 2 without remainder. Demonstrate that, 2341 K 2 (mod 341) (disproving the only if condition). Hint: It is not necessary to, calculate 2341; play around with the congruences instead.
Page 83 :
82, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, 2.31, 2.32, , 2.33, , Show that, if n is an odd composite integer, then the Miller–Rabin test will return, inconclusive for a = 1 and a = (n - 1)., If n is composite and passes the Miller–Rabin test for the base a, then n is called, a strong pseudoprime to the base a. Show that 2047 is a strong pseudoprime to the, base 2., A common formulation of the Chinese remainder theorem (CRT) is as follows: Let, m1, c , mk be integers that are pairwise relatively prime for 1 … i, j … k, and i ≠ j., Define M to be the product of all the mi >s. Let a1, c , ak be integers. Then the set of, congruences:, x K a1(mod m1), x K a2(mod m2), ~, ~, ~, x K ak(mod mk), , 2.34, , has a unique solution modulo M. Show that the theorem stated in this form is true., The example used by Sun-Tsu to illustrate the CRT was, x K 2 (mod 3); x K 3 (mod 5); x K 2 (mod 7), , 2.35, , 2.36, 2.37, , Solve for x., Six professors begin courses on Monday, Tuesday, Wednesday, Thursday, Friday,, and Saturday, respectively, and announce their intentions of lecturing at intervals of, 3, 2, 5, 6, 1, and 4 days, respectively. The regulations of the university forbid Sunday, lectures (so that a Sunday lecture must be omitted). When first will all six professors, find themselves compelled to omit a lecture? Hint: Use the CRT., Find all primitive roots of 37., Given 5 as a primitive root of 23, construct a table of discrete logarithms, and use it to, solve the following congruences., a. 3x5 K 2 (mod 23), b. 7x10 + 1 K 0 (mod 23), c. 5x K 6 (mod 23), , Programming Problems, 2.1, 2.2, , Write a computer program that implements fast exponentiation (successive squaring), modulo n., Write a computer program that implements the Miller–Rabin algorithm for a userspecified n. The program should allow the user two choices: (1) specify a possible, witness a to test using the Witness procedure or (2) specify a number s of random, witnesses for the Miller–Rabin test to check., , APPENDIX 2A, , THE MEANING OF MOD, , The operator mod is used in this book and in the literature in two different ways: as, a binary operator and as a congruence relation. This appendix explains the distinction and precisely defines the notation used in this book regarding parentheses. This, notation is common but, unfortunately, not universal., , Hiva-Network.Com
Page 84 :
APPENDIX 2A / THE MEANING OF MOD, , 83, , The Binary Operator mod, If a is an integer and n is a positive integer, we define a mod n to be the remainder, when a is divided by n. The integer n is called the modulus, and the remainder is, called the residue. Thus, for any integer a, we can always write, a = : a/n ; * n + (a mod n), Formally, we define the operator mod as, a mod n = a - : a/n ; * n for n ≠ 0, As a binary operation, mod takes two integer arguments and returns the remainder. For example, 7 mod 3 = 1. The arguments may be integers, integer variables, or integer variable expressions. For example, all of the following are valid,, with the obvious meanings:, 7 mod 3, 7 mod m, x mod 3, x mod m, (x2 + y + 1) mod (2m + n), where all of the variables are integers. In each case, the left-hand term is divided by, the right-hand term, and the resulting value is the remainder. Note that if either the, left- or right-hand argument is an expression, the expression is parenthesized. The, operator mod is not inside parentheses., In fact, the mod operation also works if the two arguments are arbitrary real numbers, not just integers. In this book, we are concerned only with the integer operation., , The Congruence Relation mod, As a congruence relation, mod expresses that two arguments have the same remainder with respect to a given modulus. For example, 7 K 4 (mod 3) expresses the, fact that both 7 and 4 have a remainder of 1 when divided by 3. The following two, expressions are equivalent:, a K b (mod m), , 3, , a mod m = b mod m, , Another way of expressing it is to say that the expression a K b (mod m) is the, same as saying that a - b is an integral multiple of m. Again, all the arguments may, be integers, integer variables, or integer variable expressions. For example, all of, the following are valid, with the obvious meanings:, 7 K 4 (mod 3), x K y (mod m), (x2 + y + 1) K (a + 1)(mod [m + n]), where all of the variables are integers. Two conventions are used. The congruence, sign is K. The modulus for the relation is defined by placing the mod operator followed by the modulus in parentheses.
Page 85 :
84, , CHAPTER 2 / INTRODUCTION TO NUMBER THEORY, , The congruence relation is used to define residue classes. Those numbers that, have the same remainder r when divided by m form a residue class (mod m). There, are m residue classes (mod m). For a given remainder r, the residue class to which it, belongs consists of the numbers, r, r { m, r { 2m, c, According to our definition, the congruence, a K b (mod m), signifies that the numbers a and b differ by a multiple of m. Consequently, the congruence can also be expressed in the terms that a and b belong to the same residue, class (mod m).
Page 86 :
PART TWO: SYMMETRIC CIPHERS, CHAPTER, , Classical Encryption Techniques, 3.1, , Symmetric Cipher Model, Cryptography, Cryptanalysis and Brute-Force Attack, , 3.2, , Substitution Techniques, Caesar Cipher, Monoalphabetic Ciphers, Playfair Cipher, Hill Cipher, Polyalphabetic Ciphers, One-Time Pad, , 3.3, , Transposition Techniques, , 3.4, , Rotor Machines, , 3.5, , Steganography, , 3.6, , Key Terms, Review Questions, and Problems, , 85
Page 87 :
86, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, ◆, , Present an overview of the main concepts of symmetric cryptography., Explain the difference between cryptanalysis and brute-force attack., Understand the operation of a monoalphabetic substitution cipher., Understand the operation of a polyalphabetic cipher., Present an overview of the Hill cipher., Describe the operation of a rotor machine., , Symmetric encryption, also referred to as conventional encryption or single-key, encryption, was the only type of encryption in use prior to the development of publickey encryption in the 1970s. It remains by far the most widely used of the two types, of encryption. Part One examines a number of symmetric ciphers. In this chapter, we, begin with a look at a general model for the symmetric encryption process; this will, enable us to understand the context within which the algorithms are used. Next, we, examine a variety of algorithms in use before the computer era. Finally, we look briefly, at a different approach known as steganography. Chapters 4 and 6 introduce the two, most widely used symmetric cipher: DES and AES., Before beginning, we define some terms. An original message is known as the, plaintext, while the coded message is called the ciphertext. The process of converting from plaintext to ciphertext is known as enciphering or encryption; restoring the, plaintext from the ciphertext is deciphering or decryption. The many schemes used, for encryption constitute the area of study known as cryptography. Such a scheme, is known as a cryptographic system or a cipher. Techniques used for deciphering a, message without any knowledge of the enciphering details fall into the area of cryptanalysis. Cryptanalysis is what the layperson calls “breaking the code.” The areas of, cryptography and cryptanalysis together are called cryptology., , 3.1 SYMMETRIC CIPHER MODEL, A symmetric encryption scheme has five ingredients (Figure 3.1):, ■, ■, ■, , Plaintext: This is the original intelligible message or data that is fed into the, algorithm as input., Encryption algorithm: The encryption algorithm performs various substitutions and transformations on the plaintext., Secret key: The secret key is also input to the encryption algorithm. The key is, a value independent of the plaintext and of the algorithm. The algorithm will, produce a different output depending on the specific key being used at the, time. The exact substitutions and transformations performed by the algorithm, depend on the key.
Page 88 :
3.1 / SYMMETRIC CIPHER MODEL, Secret key shared by, sender and recipient, , Secret key shared by, sender and recipient, , K, , K, Transmitted, ciphertext, , X, , Y = E(K, X ), Plaintext, input, , Figure 3.1, ■, , ■, , 87, , Encryption algorithm, (e.g., AES), , X = D(K, Y ), Decryption algorithm, (reverse of encryption, algorithm), , Plaintext, output, , Simplified Model of Symmetric Encryption, , Ciphertext: This is the scrambled message produced as output. It depends on, the plaintext and the secret key. For a given message, two different keys will, produce two different ciphertexts. The ciphertext is an apparently random, stream of data and, as it stands, is unintelligible., Decryption algorithm: This is essentially the encryption algorithm run in, reverse. It takes the ciphertext and the secret key and produces the original, plaintext., There are two requirements for secure use of conventional encryption:, , 1. We need a strong encryption algorithm. At a minimum, we would like the algorithm to be such that an opponent who knows the algorithm and has access to, one or more ciphertexts would be unable to decipher the ciphertext or figure, out the key. This requirement is usually stated in a stronger form: The opponent should be unable to decrypt ciphertext or discover the key even if he or, she is in possession of a number of ciphertexts together with the plaintext that, produced each ciphertext., 2. Sender and receiver must have obtained copies of the secret key in a secure, fashion and must keep the key secure. If someone can discover the key and, knows the algorithm, all communication using this key is readable., We assume that it is impractical to decrypt a message on the basis of the, ciphertext plus knowledge of the encryption/decryption algorithm. In other words,, we do not need to keep the algorithm secret; we need to keep only the key secret., This feature of symmetric encryption is what makes it feasible for widespread use., The fact that the algorithm need not be kept secret means that manufacturers can, and have developed low-cost chip implementations of data encryption algorithms., These chips are widely available and incorporated into a number of products. With, the use of symmetric encryption, the principal security problem is maintaining the, secrecy of the key., Let us take a closer look at the essential elements of a symmetric encryption scheme, using Figure 3.2. A source produces a message in plaintext,, X = [X1, X2, c , XM]. The M elements of X are letters in some finite alphabet., Traditionally, the alphabet usually consisted of the 26 capital letters. Nowadays,
Page 89 :
88, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , X, Cryptanalyst, , K, , Message, source, , X, , Encryption, algorithm, , Y = E(K, X), , Decryption, algorithm, , X, Destination, , K, , Secure channel, Key, source, , Figure 3.2 Model of Symmetric Cryptosystem, , the binary alphabet {0, 1} is typically used. For encryption, a key of the form, K = [K1, K2, c , KJ] is generated. If the key is generated at the message source,, then it must also be provided to the destination by means of some secure channel., Alternatively, a third party could generate the key and securely deliver it to both, source and destination., With the message X and the encryption key K as input, the encryption algorithm forms the ciphertext Y = [Y1, Y2, c , YN]. We can write this as, Y = E(K, X), This notation indicates that Y is produced by using encryption algorithm E as a, function of the plaintext X, with the specific function determined by the value of, the key K., The intended receiver, in possession of the key, is able to invert the, transformation:, X = D(K, Y), An opponent, observing Y but not having access to K or X, may attempt to, recover X or K or both X and K. It is assumed that the opponent knows the encryption (E) and decryption (D) algorithms. If the opponent is interested in only this, particular message, then the focus of the effort is to recover X by generating a plainn . Often, however, the opponent is interested in being able to read, text estimate X, future messages as well, in which case an attempt is made to recover K by generatn., ing an estimate K
Page 90 :
3.1 / SYMMETRIC CIPHER MODEL, , 89, , Cryptography, Cryptographic systems are characterized along three independent dimensions:, 1. The type of operations used for transforming plaintext to ciphertext. All, encryption algorithms are based on two general principles: substitution,, in which each element in the plaintext (bit, letter, group of bits or letters), is mapped into another element, and transposition, in which elements, in the plaintext are rearranged. The fundamental requirement is that no, information be lost (i.e., that all operations are reversible). Most systems,, referred to as product systems, involve multiple stages of substitutions and, transpositions., 2. The number of keys used. If both sender and receiver use the same key, the, system is referred to as symmetric, single-key, secret-key, or conventional, encryption. If the sender and receiver use different keys, the system is referred, to as asymmetric, two-key, or public-key encryption., 3. The way in which the plaintext is processed. A block cipher processes the input, one block of elements at a time, producing an output block for each input, block. A stream cipher processes the input elements continuously, producing, output one element at a time, as it goes along., , Cryptanalysis and Brute-Force Attack, Typically, the objective of attacking an encryption system is to recover the key in, use rather than simply to recover the plaintext of a single ciphertext. There are two, general approaches to attacking a conventional encryption scheme:, ■, , Cryptanalysis: Cryptanalytic attacks rely on the nature of the algorithm plus, perhaps some knowledge of the general characteristics of the plaintext or even, some sample plaintext–ciphertext pairs. This type of attack exploits the characteristics of the algorithm to attempt to deduce a specific plaintext or to deduce, the key being used., , ■, , Brute-force attack: The attacker tries every possible key on a piece of ciphertext until an intelligible translation into plaintext is obtained. On average, half, of all possible keys must be tried to achieve success., , If either type of attack succeeds in deducing the key, the effect is catastrophic:, All future and past messages encrypted with that key are compromised., We first consider cryptanalysis and then discuss brute-force attacks., Table 3.1 summarizes the various types of cryptanalytic attacks based on the, amount of information known to the cryptanalyst. The most difficult problem is, presented when all that is available is the ciphertext only. In some cases, not even, the encryption algorithm is known, but in general, we can assume that the opponent, does know the algorithm used for encryption. One possible attack under these circumstances is the brute-force approach of trying all possible keys. If the key space, is very large, this becomes impractical. Thus, the opponent must rely on an analysis, of the ciphertext itself, generally applying various statistical tests to it. To use this
Page 91 :
90, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , Table 3.1 Types of Attacks on Encrypted Messages, Type of Attack, Ciphertext Only, , Known to Cryptanalyst, ■, ■, , Known Plaintext, , Encryption algorithm, Ciphertext, , Encryption algorithm, Ciphertext, ■ One or more plaintext–ciphertext pairs formed with the secret key, ■, ■, , Chosen Plaintext, , Encryption algorithm, Ciphertext, ■ Plaintext message chosen by cryptanalyst, together with its corresponding, ciphertext generated with the secret key, ■, ■, , Chosen Ciphertext, , Encryption algorithm, Ciphertext, ■ Ciphertext chosen by cryptanalyst, together with its corresponding decrypted, plaintext generated with the secret key, ■, ■, , Chosen Text, , Encryption algorithm, Ciphertext, ■ Plaintext message chosen by cryptanalyst, together with its corresponding, ciphertext generated with the secret key, ■ Ciphertext chosen by cryptanalyst, together with its corresponding decrypted, plaintext generated with the secret key, ■, ■, , approach, the opponent must have some general idea of the type of plaintext that, is concealed, such as English or French text, an EXE file, a Java source listing, an, accounting file, and so on., The ciphertext-only attack is the easiest to defend against because the opponent has the least amount of information to work with. In many cases, however,, the analyst has more information. The analyst may be able to capture one or more, plaintext messages as well as their encryptions. Or the analyst may know that certain, plaintext patterns will appear in a message. For example, a file that is encoded in the, Postscript format always begins with the same pattern, or there may be a standardized header or banner to an electronic funds transfer message, and so on. All these, are examples of known plaintext. With this knowledge, the analyst may be able to, deduce the key on the basis of the way in which the known plaintext is transformed., Closely related to the known-plaintext attack is what might be referred to as a, probable-word attack. If the opponent is working with the encryption of some general prose message, he or she may have little knowledge of what is in the message., However, if the opponent is after some very specific information, then parts of the, message may be known. For example, if an entire accounting file is being transmitted, the opponent may know the placement of certain key words in the header of the, file. As another example, the source code for a program developed by Corporation, X might include a copyright statement in some standardized position., If the analyst is able somehow to get the source system to insert into the system a message chosen by the analyst, then a chosen-plaintext attack is possible., An example of this strategy is differential cryptanalysis, explored in Appendix S.
Page 92 :
3.1 / SYMMETRIC CIPHER MODEL, , 91, , In general, if the analyst is able to choose the messages to encrypt, the analyst may, deliberately pick patterns that can be expected to reveal the structure of the key., Table 3.1 lists two other types of attack: chosen ciphertext and chosen text., These are less commonly employed as cryptanalytic techniques but are nevertheless, possible avenues of attack., Only relatively weak algorithms fail to withstand a ciphertext-only attack., Generally, an encryption algorithm is designed to withstand a known-plaintext, attack., Two more definitions are worthy of note. An encryption scheme is, unconditionally secure if the ciphertext generated by the scheme does not contain, enough information to determine uniquely the corresponding plaintext, no matter, how much ciphertext is available. That is, no matter how much time an opponent, has, it is impossible for him or her to decrypt the ciphertext simply because the, required information is not there. With the exception of a scheme known as the, one-time pad (described later in this chapter), there is no encryption algorithm that, is unconditionally secure. Therefore, all that the users of an encryption algorithm, can strive for is an algorithm that meets one or both of the following criteria:, ■, ■, , The cost of breaking the cipher exceeds the value of the encrypted information., The time required to break the cipher exceeds the useful lifetime of the, information., , An encryption scheme is said to be computationally secure if either of the, foregoing two criteria are met. Unfortunately, it is very difficult to estimate the, amount of effort required to cryptanalyze ciphertext successfully., All forms of cryptanalysis for symmetric encryption schemes are designed, to exploit the fact that traces of structure or pattern in the plaintext may survive, encryption and be discernible in the ciphertext. This will become clear as we examine various symmetric encryption schemes in this chapter. We will see in Part Two, that cryptanalysis for public-key schemes proceeds from a fundamentally different, premise, namely, that the mathematical properties of the pair of keys may make it, possible for one of the two keys to be deduced from the other., A brute-force attack involves trying every possible key until an intelligible, translation of the ciphertext into plaintext is obtained. On average, half of all possible keys must be tried to achieve success. That is, if there are X different keys, on, average an attacker would discover the actual key after X/2 tries. It is important to, note that there is more to a brute-force attack than simply running through all possible keys. Unless known plaintext is provided, the analyst must be able to recognize, plaintext as plaintext. If the message is just plain text in English, then the result pops, out easily, although the task of recognizing English would have to be automated. If, the text message has been compressed before encryption, then recognition is more, difficult. And if the message is some more general type of data, such as a numerical file, and this has been compressed, the problem becomes even more difficult to, automate. Thus, to supplement the brute-force approach, some degree of knowledge about the expected plaintext is needed, and some means of automatically distinguishing plaintext from garble is also needed., , Hiva-Network.Com
Page 93 :
92, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , 3.2 SUBSTITUTION TECHNIQUES, In this section and the next, we examine a sampling of what might be called classical, encryption techniques. A study of these techniques enables us to illustrate the basic, approaches to symmetric encryption used today and the types of cryptanalytic attacks that must be anticipated., The two basic building blocks of all encryption techniques are substitution, and transposition. We examine these in the next two sections. Finally, we discuss a, system that combines both substitution and transposition., A substitution technique is one in which the letters of plaintext are replaced, by other letters or by numbers or symbols.1 If the plaintext is viewed as a sequence, of bits, then substitution involves replacing plaintext bit patterns with ciphertext bit, patterns., , Caesar Cipher, The earliest known, and the simplest, use of a substitution cipher was by Julius, Caesar. The Caesar cipher involves replacing each letter of the alphabet with the, letter standing three places further down the alphabet. For example,, plain: meet me after the toga party, cipher: PHHW PH DIWHU WKH WRJD SDUWB, Note that the alphabet is wrapped around, so that the letter following Z is A., We can define the transformation by listing all possibilities, as follows:, plain: a b c d e f g h i j k l m n o p q r s t u v w x y z, cipher: D E F G H I J K L M N O P Q R S T U V W X Y Z A B C, Let us assign a numerical equivalent to each letter:, a, , b, , c, , d, , e, , f, , g, , h, , i, , j, , k, , l, , m, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , 11, , 12, , n, , o, , p, , q, , r, , s, , t, , u, , v, , w, , x, , y, , z, , 13, , 14, , 15, , 16, , 17, , 18, , 19, , 20, , 21, , 22, , 23, , 24, , 25, , Then the algorithm can be expressed as follows. For each plaintext letter p, substitute the ciphertext letter C:2, C = E(3, p) = (p + 3) mod 26, A shift may be of any amount, so that the general Caesar algorithm is, C = E(k, p) = (p + k) mod 26, , (3.1), , 1, , When letters are involved, the following conventions are used in this book. Plaintext is always in, lowercase; ciphertext is in uppercase; key values are in italicized lowercase., , We define a mod n to be the remainder when a is divided by n. For example, 11 mod 7 = 4. See Chapter 2, for a further discussion of modular arithmetic., , 2
Page 95 :
94, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , Figure 3.4, , Sample of Compressed Text, , examined in Chapter 7, makes use of a 168-bit key, giving a key space of 2168 or, greater than 3.7 * 1050 possible keys., The third characteristic is also significant. If the language of the plaintext is, unknown, then plaintext output may not be recognizable. Furthermore, the input, may be abbreviated or compressed in some fashion, again making recognition difficult. For example, Figure 3.4 shows a portion of a text file compressed using an, algorithm called ZIP. If this file is then encrypted with a simple substitution cipher, (expanded to include more than just 26 alphabetic characters), then the plaintext, may not be recognized when it is uncovered in the brute-force cryptanalysis., , Monoalphabetic Ciphers, With only 25 possible keys, the Caesar cipher is far from secure. A dramatic increase, in the key space can be achieved by allowing an arbitrary substitution. Before proceeding, we define the term permutation. A permutation of a finite set of elements S, is an ordered sequence of all the elements of S, with each element appearing exactly, once. For example, if S = {a, b, c}, there are six permutations of S:, abc, acb, bac, bca, cab, cba, In general, there are n! permutations of a set of n elements, because the first, element can be chosen in one of n ways, the second in n - 1 ways, the third in n - 2, ways, and so on., Recall the assignment for the Caesar cipher:, plain: a b c d e f g h i j k l m n o p q r s t u v w x y z, cipher: D E F G H I J K L M N O P Q R S T U V W X Y Z A B C, If, instead, the “cipher” line can be any permutation of the 26 alphabetic characters,, then there are 26! or greater than 4 * 1026 possible keys. This is 10 orders of magnitude greater than the key space for DES and would seem to eliminate brute-force, techniques for cryptanalysis. Such an approach is referred to as a monoalphabetic, substitution cipher, because a single cipher alphabet (mapping from plain alphabet, to cipher alphabet) is used per message., There is, however, another line of attack. If the cryptanalyst knows the nature, of the plaintext (e.g., noncompressed English text), then the analyst can exploit the, regularities of the language. To see how such a cryptanalysis might proceed, we give, a partial example here that is adapted from one in [SINK09]. The ciphertext to be, solved is
Page 96 :
3.2 / SUBSTITUTION TECHNIQUES, , 95, , UZQSOVUOHXMOPVGPOZPEVSGZWSZOPFPESXUDBMETSXAIZ, VUEPHZHMDZSHZOWSFPAPPDTSVPQUZWYMXUZUHSX, EPYEPOPDZSZUFPOMBZWPFUPZHMDJUDTMOHMQ, As a first step, the relative frequency of the letters can be determined and, compared to a standard frequency distribution for English, such as is shown in, Figure 3.5 (based on [LEWA00]). If the message were long enough, this technique, alone might be sufficient, but because this is a relatively short message, we cannot, expect an exact match. In any case, the relative frequencies of the letters in the, ciphertext (in percentages) are as follows:, P, , 13.33, , H, , Z, , 11.67, , D, , S, , 8.33, , E, , U, , 8.33, , V, , O, , 7.50, , X, , M, , 6.67, , 5.83, , F, , 3.33, , B, , 1.67, , C, , 5.00, , W 3.33, , 5.00, , Q, , 2.50, , 4.17, , T, , 4.17, , A, , 0.00, , G, , 1.67, , K, , 0.00, , Y, , 1.67, , L, , 0.00, , 2.50, , I, , 0.83, , N, , 0.00, , 1.67, , J, , 0.83, , R, , 0.00, , Comparing this breakdown with Figure 3.5, it seems likely that cipher letters, P and Z are the equivalents of plain letters e and t, but it is not certain which is which., The letters S, U, O, M, and H are all of relatively high frequency and probably, 12.702, , 14, , 9.056, , 12, , 0, , A B, , C D E, , F G H, , J, , K L M N O, , Figure 3.5 Relative Frequency of Letters in English Text, , P, , Q R, , S, , T U V W X Y, , 0.074, , 0.150, , 1.974, , 2.360, , 2.758, 0.095, , 0.978, , 1.929, , 2.406, I, , 0.772, , 0.153, , 2.015, , 2.228, , 1.492, , 2, , 2.782, , 4, , 4.025, , 4.253, , 6, , 6.327, , 5.987, , 7.507, , 6.749, , 6.094, , 8, , 6.996, , 8.167, , Relative frequency (% ), , 10, , Z
Page 97 :
96, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , correspond to plain letters from the set {a, h, i, n, o, r, s}. The letters with the lowest, frequencies (namely, A, B, G, Y, I, J) are likely included in the set {b, j, k, q, v, x, z}., There are a number of ways to proceed at this point. We could make some, tentative assignments and start to fill in the plaintext to see if it looks like a reasonable “skeleton” of a message. A more systematic approach is to look for other, regularities. For example, certain words may be known to be in the text. Or we, could look for repeating sequences of cipher letters and try to deduce their plaintext, equivalents., A powerful tool is to look at the frequency of two-letter combinations, known, as digrams. A table similar to Figure 3.5 could be drawn up showing the relative frequency of digrams. The most common such digram is th. In our ciphertext, the most, common digram is ZW, which appears three times. So we make the correspondence, of Z with t and W with h. Then, by our earlier hypothesis, we can equate P with e., Now notice that the sequence ZWP appears in the ciphertext, and we can translate, that sequence as “the.” This is the most frequent trigram (three-letter combination), in English, which seems to indicate that we are on the right track., Next, notice the sequence ZWSZ in the first line. We do not know that these, four letters form a complete word, but if they do, it is of the form th_t. If so, S, equates with a., So far, then, we have, UZQSOVUOHXMOPVGPOZPEVSGZWSZOPFPESXUDBMETSXAIZ, t a, e e te a that e e a, a, VUEPHZHMDZSHZOWSFPAPPDTSVPQUZWYMXUZUHSX, e t, ta t ha e ee a e th, t a, EPYEPOPDZSZUFPOMBZWPFUPZHMDJUDTMOHMQ, e e e tat e, the, t, Only four letters have been identified, but already we have quite a bit of the, message. Continued analysis of frequencies plus trial and error should easily yield a, solution from this point. The complete plaintext, with spaces added between words,, follows:, it was disclosed yesterday that several informal but, direct contacts have been made with political, representatives of the viet cong in moscow, Monoalphabetic ciphers are easy to break because they reflect the frequency, data of the original alphabet. A countermeasure is to provide multiple substitutes, known as homophones, for a single letter. For example, the letter e could, be assigned a number of different cipher symbols, such as 16, 74, 35, and 21, with, each homophone assigned to a letter in rotation or randomly. If the number of, symbols assigned to each letter is proportional to the relative frequency of that letter, then single-letter frequency information is completely obliterated. The great, mathematician Carl Friedrich Gauss believed that he had devised an unbreakable cipher using homophones. However, even with homophones, each element, of plaintext affects only one element of ciphertext, and multiple-letter patterns
Page 98 :
3.2 / SUBSTITUTION TECHNIQUES, , 97, , (e.g., digram frequencies) still survive in the ciphertext, making cryptanalysis relatively straightforward., Two principal methods are used in substitution ciphers to lessen the extent to, which the structure of the plaintext survives in the ciphertext: One approach is to, encrypt multiple letters of plaintext, and the other is to use multiple cipher alphabets. We briefly examine each., , Playfair Cipher, The best-known multiple-letter encryption cipher is the Playfair, which treats digrams in the plaintext as single units and translates these units into ciphertext, digrams.3, The Playfair algorithm is based on the use of a 5 * 5 matrix of letters constructed using a keyword. Here is an example, solved by Lord Peter Wimsey in, Dorothy Sayers’s Have His Carcase:4, M, , O, , N, , A, , R, , C, , H, , Y, , B, , D, , E, , F, , G, , I/J, , K, , L, , P, , Q, , S, , T, , U, , V, , W, , X, , Z, , In this case, the keyword is monarchy. The matrix is constructed by filling, in the letters of the keyword (minus duplicates) from left to right and from top to, bottom, and then filling in the remainder of the matrix with the remaining letters in, alphabetic order. The letters I and J count as one letter. Plaintext is encrypted two, letters at a time, according to the following rules:, 1. Repeating plaintext letters that are in the same pair are separated with a filler, letter, such as x, so that balloon would be treated as ba lx lo on., 2. Two plaintext letters that fall in the same row of the matrix are each replaced, by the letter to the right, with the first element of the row circularly following, the last. For example, ar is encrypted as RM., 3. Two plaintext letters that fall in the same column are each replaced by the letter beneath, with the top element of the column circularly following the last., For example, mu is encrypted as CM., 4. Otherwise, each plaintext letter in a pair is replaced by the letter that lies in, its own row and the column occupied by the other plaintext letter. Thus, hs, becomes BP and ea becomes IM (or JM, as the encipherer wishes)., The Playfair cipher is a great advance over simple monoalphabetic ciphers., For one thing, whereas there are only 26 letters, there are 26 * 26 = 676 digrams,, 3, This cipher was actually invented by British scientist Sir Charles Wheatstone in 1854, but it bears the, name of his friend Baron Playfair of St. Andrews, who championed the cipher at the British foreign office., 4, , The book provides an absorbing account of a probable-word attack.
Page 99 :
CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , so that identification of individual digrams is more difficult. Furthermore, the relative frequencies of individual letters exhibit a much greater range than that of, digrams, making frequency analysis much more difficult. For these reasons, the, Playfair cipher was for a long time considered unbreakable. It was used as the standard field system by the British Army in World War I and still enjoyed considerable, use by the U.S. Army and other Allied forces during World War II., Despite this level of confidence in its security, the Playfair cipher is relatively, easy to break, because it still leaves much of the structure of the plaintext language, intact. A few hundred letters of ciphertext are generally sufficient., One way of revealing the effectiveness of the Playfair and other ciphers is, shown in Figure 3.6. The line labeled plaintext plots a typical frequency distribution, of the 26 alphabetic characters (no distinction between upper and lower case) in, ordinary text. This is also the frequency distribution of any monoalphabetic substitution cipher, because the frequency values for individual letters are the same, just, with different letters substituted for the original letters. The plot is developed in the, following way: The number of occurrences of each letter in the text is counted and, divided by the number of occurrences of the most frequently used letter. Using the, results of Figure 3.5, we see that e is the most frequently used letter. As a result, e, has a relative frequency of 1, t of 9.056/12.702 ≈ 0.72, and so on. The points on the, horizontal axis correspond to the letters in order of decreasing frequency., Figure 3.6 also shows the frequency distribution that results when the text is, encrypted using the Playfair cipher. To normalize the plot, the number of occurrences of each letter in the ciphertext was again divided by the number of occurrences of e in the plaintext. The resulting plot therefore shows the extent to which, the frequency distribution of letters, which makes it trivial to solve substitution, 1.0, 0.9, Plaintext, 0.8, Normalized relative frequency, , 98, , Playfair, , 0.7, 0.6, 0.5, 0.4, , Vigenère, , 0.3, 0.2, , Random polyalphabetic, , 0.1, 0, 1 2 3 4 5 6 1 7 8 9 10 10 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26, Frequency ranked letters (decreasing frequency), , Figure 3.6, , Relative Frequency of Occurrence of Letters
Page 100 :
3.2 / SUBSTITUTION TECHNIQUES, , 99, , ciphers, is masked by encryption. If the frequency distribution information were, totally concealed in the encryption process, the ciphertext plot of frequencies would, be flat, and cryptanalysis using ciphertext only would be effectively impossible. As, the figure shows, the Playfair cipher has a flatter distribution than does plaintext,, but nevertheless, it reveals plenty of structure for a cryptanalyst to work with. The, plot also shows the Vigenère cipher, discussed subsequently. The Hill and Vigenère, curves on the plot are based on results reported in [SIMM93]., , Hill Cipher5, Another interesting multiletter cipher is the Hill cipher, developed by the mathematician Lester Hill in 1929., CONCEPTS FROM LINEAR ALGEBRA Before describing the Hill cipher, let us briefly, review some terminology from linear algebra. In this discussion, we are concerned, with matrix arithmetic modulo 26. For the reader who needs a refresher on matrix, multiplication and inversion, see Appendix E., We define the inverse M -1 of a square matrix M by the equation M(M -1) =, -1, M M = I, where I is the identity matrix. I is a square matrix that is all zeros except, for ones along the main diagonal from upper left to lower right. The inverse of a, matrix does not always exist, but when it does, it satisfies the preceding equation., For example,, A = ¢, AA-1 = ¢, = ¢, , 5, 17, , 8, ≤, 3, , A-1 mod 26 = ¢, , (5 * 9) + (8 * 1), (17 * 9) + (3 * 1), 53, 156, , 9, 1, , 2, ≤, 15, , (5 * 2) + (8 * 15), ≤, (17 * 2) + (3 * 15), , 130, 1, ≤ mod 26 = ¢, 79, 0, , 0, ≤, 1, , To explain how the inverse of a matrix is computed, we begin with the concept, of determinant. For any square matrix (m * m), the determinant equals the sum of, all the products that can be formed by taking exactly one element from each row, and exactly one element from each column, with certain of the product terms preceded by a minus sign. For a 2 * 2 matrix,, ¢, , k11, k21, , k12, ≤, k22, , the determinant is k11k22 - k12k21. For a 3 * 3 matrix, the value of the determinant, is k11k22k33 + k21k32k13 + k31k12k23 - k31k22k13 - k21k12k33 - k11k32k23. If a square, , 5, , This cipher is somewhat more difficult to understand than the others in this chapter, but it illustrates an, important point about cryptanalysis that will be useful later on. This subsection can be skipped on a first, reading.
Page 101 :
100, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , matrix A has a nonzero determinant, then the inverse of the matrix is computed, as [A-1]ij = (det A)-1( -1)i + j(Dji), where (Dji) is the subdeterminant formed by, deleting the jth row and the ith column of A, det(A) is the determinant of A, and, (det A)-1 is the multiplicative inverse of (det A) mod 26., Continuing our example,, det ¢, , 5, 17, , 8, ≤ = (5 * 3) - (8 * 17) = -121 mod 26 = 9, 3, , We can show that 9-1 mod 26 = 3, because 9 * 3 = 27 mod 26 = 1 (see, Chapter 2 or Appendix E). Therefore, we compute the inverse of A as, A = ¢, , 5, 17, , A-1 mod 26 = 3¢, , 8, ≤, 3, , 3, -17, , -8, 3, ≤ = 3¢, 5, 9, , 18, 9, ≤ = ¢, 5, 27, , 54, 9, ≤ = ¢, 15, 1, , 2, ≤, 15, , THE HILL ALGORITHM This encryption algorithm takes m successive plaintext letters and substitutes for them m ciphertext letters. The substitution is determined, by m linear equations in which each character is assigned a numerical value, (a = 0, b = 1, c , z = 25). For m = 3, the system can be described as, c1 = (k11p1 + k21p2 + k31p3) mod 26, c2 = (k12p1 + k22p2 + k32p3) mod 26, c3 = (k13p1 + k23p2 + k33p3) mod 26, This can be expressed in terms of row vectors and matrices:6, k11, (c1 c2 c3) = (p1 p2 p3) £ k21, k31, , k12, k22, k32, , k13, k23 ≥ mod 26, k33, , or, C = PK mod 26, where C and P are row vectors of length 3 representing the plaintext and ciphertext,, and K is a 3 * 3 matrix representing the encryption key. Operations are performed, mod 26., 6, , Some cryptography books express the plaintext and ciphertext as column vectors, so that the column, vector is placed after the matrix rather than the row vector placed before the matrix. Sage uses row vectors, so we adopt that convention., , Hiva-Network.Com
Page 102 :
3.2 / SUBSTITUTION TECHNIQUES, , 101, , For example, consider the plaintext “paymoremoney” and use the encryption key, 17, K = £ 21, 2, , 17, 18, 2, , 5, 21 ≥, 19, , The first three letters of the plaintext are represented by the vector (15 0 24)., Then (15 0 24)K = (303 303 531) mod 26 = (17 17 11) = RRL. Continuing in this, fashion, the ciphertext for the entire plaintext is RRLMWBKASPDH., Decryption requires using the inverse of the matrix K. We can compute det, K = 23, and therefore, (det K)-1 mod 26 = 17. We can then compute the inverse as7, , K, , -1, , 4, = £ 15, 24, , 9, 17, 0, , 15, 6≥, 17, , This is demonstrated as, 17, £ 21, 2, , 17, 18, 2, , 5, 4, 21 ≥ £ 15, 19 24, , 9, 17, 0, , 15, 443, 6 ≥ = £ 858, 17, 494, , 442, 495, 52, , 442, 1, 780 ≥ mod 26 = £ 0, 365, 0, , 0, 1, 0, , 0, 0≥, 1, , It is easily seen that if the matrix K-1 is applied to the ciphertext, then the, plaintext is recovered., In general terms, the Hill system can be expressed as, C = E(K, P) = PK mod 26, P = D(K, C) = CK-1 mod 26 = PKK-1 = P, As with Playfair, the strength of the Hill cipher is that it completely hides, single-letter frequencies. Indeed, with Hill, the use of a larger matrix hides more, frequency information. Thus, a 3 * 3 Hill cipher hides not only single-letter but, also two-letter frequency information., Although the Hill cipher is strong against a ciphertext-only attack, it is easily, broken with a known plaintext attack. For an m * m Hill cipher, suppose we have m, plaintext–ciphertext pairs, each of length m. We label the pairs Pj = (p1jp1j c pmj), and Cj = (c1jc1j c cmj) such that Cj = PjK for 1 … j … m and for some unknown, key matrix K. Now define two m * m matrices X = (pij) and Y = (cij). Then we, can form the matrix equation Y = XK. If X has an inverse, then we can determine, K = X-1Y. If X is not invertible, then a new version of X can be formed with additional plaintext–ciphertext pairs until an invertible X is obtained., Consider this example. Suppose that the plaintext “hillcipher” is encrypted, using a 2 * 2 Hill cipher to yield the ciphertext HCRZSSXNSP. Thus, we know, that (7 8)K mod 26 = (7 2); (11 11)K mod 26 = (17 25); and so on. Using, the first two plaintext-ciphertext pairs, we have, 7, , The calculations for this example are provided in detail in Appendix E.
Page 103 :
102, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , ¢, , 7, 17, , 2, 7, ≤ = ¢, 25, 11, , 8, ≤K mod 26, 11, , The inverse of X can be computed:, ¢, , 7, 11, , 25, 8 -1, ≤ = ¢, 1, 11, , 22, ≤, 23, , so, K = ¢, , 25, 1, , 22, 7, ≤¢, 23 17, , 2, 549, ≤ = ¢, 25, 398, , 600, 3, ≤ mod 26 = ¢, 577, 8, , 2, ≤, 5, , This result is verified by testing the remaining plaintext–ciphertext pairs., , Polyalphabetic Ciphers, Another way to improve on the simple monoalphabetic technique is to use different monoalphabetic substitutions as one proceeds through the plaintext message., The general name for this approach is polyalphabetic substitution cipher. All these, techniques have the following features in common:, 1. A set of related monoalphabetic substitution rules is used., 2. A key determines which particular rule is chosen for a given transformation., VIGENÈRE CIPHER The best known, and one of the simplest, polyalphabetic ciphers, is the Vigenère cipher. In this scheme, the set of related monoalphabetic substitution rules consists of the 26 Caesar ciphers with shifts of 0 through 25. Each cipher is, denoted by a key letter, which is the ciphertext letter that substitutes for the plaintext letter a. Thus, a Caesar cipher with a shift of 3 is denoted by the key value 3.8, We can express the Vigenère cipher in the following manner. Assume a, sequence of plaintext letters P = p0, p1, p2, c , pn - 1 and a key consisting of the, sequence of letters K = k0, k1, k2, c , km - 1, where typically m 6 n. The sequence, of ciphertext letters C = C0, C1, C2, c , Cn - 1 is calculated as follows:, C = C0, C1, C2, c , Cn - 1 = E(K, P) = E[(k0, k1, k2, c , km - 1), (p0, p1, p2, c , pn - 1)], = (p0 + k0) mod 26, (p1 + k1) mod 26, c ,(pm - 1 + km - 1) mod 26,, (pm + k0) mod 26, (pm + 1 + k1) mod 26, c , (p2m - 1 + km - 1) mod 26, c, Thus, the first letter of the key is added to the first letter of the plaintext, mod 26,, the second letters are added, and so on through the first m letters of the plaintext., For the next m letters of the plaintext, the key letters are repeated. This process, , 8, , To aid in understanding this scheme and also to aid in it use, a matrix known as the Vigenère tableau is, often used. This tableau is discussed in a document at box.com/Crypto7e.
Page 104 :
3.2 / SUBSTITUTION TECHNIQUES, , 103, , continues until all of the plaintext sequence is encrypted. A general equation of the, encryption process is, Ci = (pi + ki mod m) mod 26, , (3.3), , Compare this with Equation (3.1) for the Caesar cipher. In essence, each plaintext character is encrypted with a different Caesar cipher, depending on the corresponding key character. Similarly, decryption is a generalization of Equation (3.2):, pi = (Ci - ki mod m) mod 26, , (3.4), , To encrypt a message, a key is needed that is as long as the message. Usually,, the key is a repeating keyword. For example, if the keyword is deceptive, the message “we are discovered save yourself” is encrypted as, key:, plaintext:, ciphertext:, , deceptivedeceptivedeceptive, wearediscoveredsaveyourself, ZICVTWQNGRZGVTWAVZHCQYGLMGJ, , Expressed numerically, we have the following result., key, , 3, , 4, , 2, , 4, , 15, , 19, , 8, , 21, , 4, , 3, , 4, , 2, , 4, , 15, , plaintext, , 22, , 4, , 0, , 17, , 4, , 3, , 8, , 18, , 2, , 14, , 21, , 4, , 17, , 4, , ciphertext, , 25, , 8, , 2, , 21, , 19, , 22, , 16, , 13, , 6, , 17, , 25, , 6, , 21, , 19, , key, , 19, , 8, , 21, , 4, , 3, , 4, , 2, , 4, , 15, , 19, , 8, , 21, , 4, , plaintext, , 3, , 18, , 0, , 21, , 4, , 24, , 14, , 20, , 17, , 18, , 4, , 11, , 5, , ciphertext, , 22, , 0, , 21, , 25, , 7, , 2, , 16, , 24, , 6, , 11, , 12, , 6, , 9, , The strength of this cipher is that there are multiple ciphertext letters for, each plaintext letter, one for each unique letter of the keyword. Thus, the letter frequency information is obscured. However, not all knowledge of the plaintext structure is lost. For example, Figure 3.6 shows the frequency distribution for a Vigenère, cipher with a keyword of length 9. An improvement is achieved over the Playfair, cipher, but considerable frequency information remains., It is instructive to sketch a method of breaking this cipher, because the method, reveals some of the mathematical principles that apply in cryptanalysis., First, suppose that the opponent believes that the ciphertext was encrypted, using either monoalphabetic substitution or a Vigenère cipher. A simple test can, be made to make a determination. If a monoalphabetic substitution is used, then, the statistical properties of the ciphertext should be the same as that of the language of the plaintext. Thus, referring to Figure 3.5, there should be one cipher letter with a relative frequency of occurrence of about 12.7%, one with about 9.06%,, and so on. If only a single message is available for analysis, we would not expect, an exact match of this small sample with the statistical profile of the plaintext language. Nevertheless, if the correspondence is close, we can assume a monoalphabetic substitution.
Page 105 :
104, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , If, on the other hand, a Vigenère cipher is suspected, then progress depends on, determining the length of the keyword, as will be seen in a moment. For now, let us, concentrate on how the keyword length can be determined. The important insight, that leads to a solution is the following: If two identical sequences of plaintext letters occur at a distance that is an integer multiple of the keyword length, they will, generate identical ciphertext sequences. In the foregoing example, two instances, of the sequence “red” are separated by nine character positions. Consequently, in, both cases, r is encrypted using key letter e, e is encrypted using key letter p, and d, is encrypted using key letter t. Thus, in both cases, the ciphertext sequence is VTW., We indicate this above by underlining the relevant ciphertext letters and shading, the relevant ciphertext numbers., An analyst looking at only the ciphertext would detect the repeated sequences, VTW at a displacement of 9 and make the assumption that the keyword is either, three or nine letters in length. The appearance of VTW twice could be by chance, and may not reflect identical plaintext letters encrypted with identical key letters., However, if the message is long enough, there will be a number of such repeated, ciphertext sequences. By looking for common factors in the displacements of the various sequences, the analyst should be able to make a good guess of the keyword length., Solution of the cipher now depends on an important insight. If the keyword, length is m, then the cipher, in effect, consists of m monoalphabetic substitution, ciphers. For example, with the keyword DECEPTIVE, the letters in positions 1, 10,, 19, and so on are all encrypted with the same monoalphabetic cipher. Thus, we can, use the known frequency characteristics of the plaintext language to attack each of, the monoalphabetic ciphers separately., The periodic nature of the keyword can be eliminated by using a nonrepeating, keyword that is as long as the message itself. Vigenère proposed what is referred to, as an autokey system, in which a keyword is concatenated with the plaintext itself to, provide a running key. For our example,, key:, plaintext:, ciphertext:, , deceptivewearediscoveredsav, wearediscoveredsaveyourself, ZICVTWQNGKZEIIGASXSTSLVVWLA, , Even this scheme is vulnerable to cryptanalysis. Because the key and the, plaintext share the same frequency distribution of letters, a statistical technique can, be applied. For example, e enciphered by e, by Figure 3.5, can be expected to occur, with a frequency of (0.127)2 ≈ 0.016, whereas t enciphered by t would occur only, about half as often. These regularities can be exploited to achieve successful, cryptanalysis.9, VERNAM CIPHER The ultimate defense against such a cryptanalysis is to choose a, keyword that is as long as the plaintext and has no statistical relationship to it. Such, a system was introduced by an AT&T engineer named Gilbert Vernam in 1918., , 9, Although the techniques for breaking a Vigenère cipher are by no means complex, a 1917 issue of, Scientific American characterized this system as “impossible of translation.” This is a point worth remembering when similar claims are made for modern algorithms.
Page 106 :
3.2 / SUBSTITUTION TECHNIQUES, Key stream, generator, , 105, , Key stream, generator, , Cryptographic, bit stream (ki), , Cryptographic, bit stream (ki), , Plaintext, (pi), , Ciphertext, (ci ), , Plaintext, (pi), , Figure 3.7 Vernam Cipher, , His system works on binary data (bits) rather than letters. The system can be, expressed succinctly as follows (Figure 3.7):, ci = pi ⊕ ki, where, pi = ith binary digit of plaintext, ki = ith binary digit of key, ci = ith binary digit of ciphertext, ⊕ = exclusive@or (XOR) operation, Compare this with Equation (3.3) for the Vigenère cipher., Thus, the ciphertext is generated by performing the bitwise XOR of the plaintext and the key. Because of the properties of the XOR, decryption simply involves, the same bitwise operation:, pi = ci ⊕ ki, which compares with Equation (3.4)., The essence of this technique is the means of construction of the key. Vernam, proposed the use of a running loop of tape that eventually repeated the key, so that, in fact the system worked with a very long but repeating keyword. Although such, a scheme, with a long key, presents formidable cryptanalytic difficulties, it can be, broken with sufficient ciphertext, the use of known or probable plaintext sequences,, or both., , One-Time Pad, An Army Signal Corp officer, Joseph Mauborgne, proposed an improvement to the, Vernam cipher that yields the ultimate in security. Mauborgne suggested using a, random key that is as long as the message, so that the key need not be repeated. In, addition, the key is to be used to encrypt and decrypt a single message, and then is, discarded. Each new message requires a new key of the same length as the new message. Such a scheme, known as a one-time pad, is unbreakable. It produces random, output that bears no statistical relationship to the plaintext. Because the ciphertext
Page 107 :
106, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , contains no information whatsoever about the plaintext, there is simply no way to, break the code., An example should illustrate our point. Suppose that we are using a Vigenère, scheme with 27 characters in which the twenty-seventh character is the space, character, but with a one-time key that is as long as the message. Consider the, ciphertext, ANKYODKYUREPFJBYOJDSPLREYIUNOFDOIUERFPLUYTS, We now show two different decryptions using two different keys:, ciphertext: ANKYODKYUREPFJBYOJDSPLREYIUNOFDOIUERFPLUYTS, key:, pxlmvmsydofuyrvzwc tnlebnecvgdupahfzzlmnyih, plaintext: mr mustard with the candlestick in the hall, ciphertext: ANKYODKYUREPFJBYOJDSPLREYIUNOFDOIUERFPLUYTS, key:, pftgpmiydgaxgoufhklllmhsqdqogtewbqfgyovuhwt, plaintext: miss scarlet with the knife in the library, Suppose that a cryptanalyst had managed to find these two keys. Two plausible plaintexts are produced. How is the cryptanalyst to decide which is the correct, decryption (i.e., which is the correct key)? If the actual key were produced in a truly, random fashion, then the cryptanalyst cannot say that one of these two keys is more, likely than the other. Thus, there is no way to decide which key is correct and therefore which plaintext is correct., In fact, given any plaintext of equal length to the ciphertext, there is a key that, produces that plaintext. Therefore, if you did an exhaustive search of all possible, keys, you would end up with many legible plaintexts, with no way of knowing which, was the intended plaintext. Therefore, the code is unbreakable., The security of the one-time pad is entirely due to the randomness of the key., If the stream of characters that constitute the key is truly random, then the stream, of characters that constitute the ciphertext will be truly random. Thus, there are no, patterns or regularities that a cryptanalyst can use to attack the ciphertext., In theory, we need look no further for a cipher. The one-time pad offers complete security but, in practice, has two fundamental difficulties:, 1. There is the practical problem of making large quantities of random keys. Any, heavily used system might require millions of random characters on a regular, basis. Supplying truly random characters in this volume is a significant task., 2. Even more daunting is the problem of key distribution and protection. For, every message to be sent, a key of equal length is needed by both sender and, receiver. Thus, a mammoth key distribution problem exists., Because of these difficulties, the one-time pad is of limited utility and is useful, primarily for low-bandwidth channels requiring very high security., The one-time pad is the only cryptosystem that exhibits what is referred to as, perfect secrecy. This concept is explored in Appendix F.
Page 108 :
3.3 / TRANSPOSITION TECHNIQUES, , 107, , 3.3 TRANSPOSITION TECHNIQUES, All the techniques examined so far involve the substitution of a ciphertext symbol, for a plaintext symbol. A very different kind of mapping is achieved by performing, some sort of permutation on the plaintext letters. This technique is referred to as a, transposition cipher., The simplest such cipher is the rail fence technique, in which the plaintext is, written down as a sequence of diagonals and then read off as a sequence of rows., For example, to encipher the message “meet me after the toga party” with a rail, fence of depth 2, we write the following:, m e m a t r h t g p r y, e t e f e t e o a a t, The encrypted message is, MEMATRHTGPRYETEFETEOAAT, This sort of thing would be trivial to cryptanalyze. A more complex scheme is, to write the message in a rectangle, row by row, and read the message off, column, by column, but permute the order of the columns. The order of the columns then, becomes the key to the algorithm. For example,, Key:, Plaintext:, , Ciphertext:, , 4 3 1 2 5 6 7, a t t a c k p, o s t p o n e, d u n t i l t, w o a m x y z, TTNAAPTMTSUOAODWCOIXKNLYPETZ, , Thus, in this example, the key is 4312567. To encrypt, start with the column, that is labeled 1, in this case column 3. Write down all the letters in that column., Proceed to column 4, which is labeled 2, then column 2, then column 1, then, columns 5, 6, and 7., A pure transposition cipher is easily recognized because it has the same letter, frequencies as the original plaintext. For the type of columnar transposition just, shown, cryptanalysis is fairly straightforward and involves laying out the ciphertext in a matrix and playing around with column positions. Digram and trigram frequency tables can be useful., The transposition cipher can be made significantly more secure by performing more than one stage of transposition. The result is a more complex permutation, that is not easily reconstructed. Thus, if the foregoing message is reencrypted using, the same algorithm,
Page 109 :
108, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , Key:, Input:, , Output:, , 4 3 1 2 5 6 7, t t n a a p t, m t s u o a o, d w c o i x k, n l y p e t z, NSCYAUOPTTWLTMDNAOIEPAXTTOKZ, , To visualize the result of this double transposition, designate the letters in the, original plaintext message by the numbers designating their position. Thus, with 28, letters in the message, the original sequence of letters is, 01 02 03 04 05 06 07 08 09 10 11 12 13 14, 15 16 17 18 19 20 21 22 23 24 25 26 27 28, After the first transposition, we have, 03 10 17 24 04 11 18 25 02 09 16 23 01 08, 15 22 05 12 19 26 06 13 20 27 07 14 21 28, which has a somewhat regular structure. But after the second transposition, we have, 17 09 05 27 24 16 12 07 10 02 22 20 03 25, 15 13 04 23 19 14 11 01 26 21 18 08 06 28, This is a much less structured permutation and is much more difficult to cryptanalyze., , 3.4 ROTOR MACHINES, The example just given suggests that multiple stages of encryption can produce an, algorithm that is significantly more difficult to cryptanalyze. This is as true of substitution ciphers as it is of transposition ciphers. Before the introduction of DES, the, most important application of the principle of multiple stages of encryption was a, class of systems known as rotor machines.10, The basic principle of the rotor machine is illustrated in Figure 3.8. The, machine consists of a set of independently rotating cylinders through which electrical pulses can flow. Each cylinder has 26 input pins and 26 output pins, with internal, wiring that connects each input pin to a unique output pin. For simplicity, only three, of the internal connections in each cylinder are shown., If we associate each input and output pin with a letter of the alphabet, then a, single cylinder defines a monoalphabetic substitution. For example, in Figure 3.8,, if an operator depresses the key for the letter A, an electric signal is applied to, , 10, , Machines based on the rotor principle were used by both Germany (Enigma) and Japan (Purple) in, World War II. The breaking of both codes by the Allies was a significant factor in the war’s outcome.
Page 110 :
3.4 / ROTOR MACHINES, Direction of motion, , A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, , 24, 25, 26, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, , 21, 3, 15, 1, 19, 10, 14, 26, 20, 8, 16, 7, 22, 4, 11, 5, 17, 9, 12, 23, 18, 2, 25, 6, 24, 13, , Fast rotor, , 26, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, , 20, 1, 6, 4, 15, 3, 14, 12, 23, 5, 16, 2, 22, 19, 11, 18, 25, 24, 13, 7, 10, 8, 21, 9, 26, 17, , 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, , 109, , Direction of motion, , 8, 18, 26, 17, 20, 22, 10, 3, 13, 11, 4, 23, 5, 24, 9, 12, 25, 16, 19, 6, 15, 21, 2, 7, 1, 14, , Medium rotor Slow rotor, (a) Initial setting, , A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, , A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, , 23, 24, 25, 26, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, , 13, 21, 3, 15, 1, 19, 10, 14, 26, 20, 8, 16, 7, 22, 4, 11, 5, 17, 9, 12, 23, 18, 2, 25, 6, 24, , 26, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, , 20, 1, 6, 4, 15, 3, 14, 12, 23, 5, 16, 2, 22, 19, 11, 18, 25, 24, 13, 7, 10, 8, 21, 9, 26, 17, , 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, , 8, 18, 26, 17, 20, 22, 10, 3, 13, 11, 4, 23, 5, 24, 9, 12, 25, 16, 19, 6, 15, 21, 2, 7, 1, 14, , A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, , Fast rotor Medium rotor Slow rotor, (b) Setting after one keystroke, , Figure 3.8 Three-Rotor Machine with Wiring Represented by Numbered Contacts, , the first pin of the first cylinder and flows through the internal connection to the, twenty-fifth output pin., Consider a machine with a single cylinder. After each input key is depressed,, the cylinder rotates one position, so that the internal connections are shifted accordingly. Thus, a different monoalphabetic substitution cipher is defined. After 26 letters of plaintext, the cylinder would be back to the initial position. Thus, we have a, polyalphabetic substitution algorithm with a period of 26., A single-cylinder system is trivial and does not present a formidable cryptanalytic task. The power of the rotor machine is in the use of multiple cylinders, in, which the output pins of one cylinder are connected to the input pins of the next., Figure 3.8 shows a three-cylinder system. The left half of the figure shows a position, in which the input from the operator to the first pin (plaintext letter a) is routed, through the three cylinders to appear at the output of the second pin (ciphertext, letter B)., With multiple cylinders, the one closest to the operator input rotates one, pin position with each keystroke. The right half of Figure 3.8 shows the system’s, configuration after a single keystroke. For every complete rotation of the inner, cylinder, the middle cylinder rotates one pin position. Finally, for every complete, rotation of the middle cylinder, the outer cylinder rotates one pin position. This, is the same type of operation seen with an odometer. The result is that there are, 26 * 26 * 26 = 17,576 different substitution alphabets used before the system, , Hiva-Network.Com
Page 111 :
110, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , repeats. The addition of fourth and fifth rotors results in periods of 456,976 and, 11,881,376 letters, respectively. Thus, a given setting of a 5-rotor machine is equivalent to a Vigenère cipher with a key length of 11,881,376., Such a scheme presents a formidable cryptanalytic challenge. If, for example,, the cryptanalyst attempts to use a letter frequency analysis approach, the analyst, is faced with the equivalent of over 11 million monoalphabetic ciphers. We might, need on the order of 50 letters in each monalphabetic cipher for a solution, which, means that the analyst would need to be in possession of a ciphertext with a length, of over half a billion letters., The significance of the rotor machine today is that it points the way to a large, class of symmetric ciphers, of which the Data Encryption Standard (DES) is the, most prominent. DES is introduced in Chapter 4., , 3.5 STEGANOGRAPHY, We conclude with a discussion of a technique that (strictly speaking), is not encryption, namely, steganography., A plaintext message may be hidden in one of two ways. The methods of, steganography conceal the existence of the message, whereas the methods of cryptography render the message unintelligible to outsiders by various transformations, of the text.11, A simple form of steganography, but one that is time-consuming to construct,, is one in which an arrangement of words or letters within an apparently innocuous, text spells out the real message. For example, the sequence of first letters of each, word of the overall message spells out the hidden message. Figure 3.9 shows an, example in which a subset of the words of the overall message is used to convey the, hidden message. See if you can decipher this; it’s not too hard., Various other techniques have been used historically; some examples are the, following [MYER91]:, ■, , ■, ■, ■, , Character marking: Selected letters of printed or typewritten text are overwritten in pencil. The marks are ordinarily not visible unless the paper is held, at an angle to bright light., Invisible ink: A number of substances can be used for writing but leave no visible trace until heat or some chemical is applied to the paper., Pin punctures: Small pin punctures on selected letters are ordinarily not visible unless the paper is held up in front of a light., Typewriter correction ribbon: Used between lines typed with a black ribbon,, the results of typing with the correction tape are visible only under a strong, light., , 11, Steganography was an obsolete word that was revived by David Kahn and given the meaning it has, today [KAHN96].
Page 112 :
3.5 / STEGANOGRAPHY, , 111, , Figure 3.9 A Puzzle for Inspector Morse, (From The Silent World of Nicholas Quinn, by Colin Dexter), , Although these techniques may seem archaic, they have contemporary equivalents. [WAYN09] proposes hiding a message by using the least significant bits of, frames on a CD. For example, the Kodak Photo CD format’s maximum resolution, is 3096 * 6144 pixels, with each pixel containing 24 bits of RGB color information., The least significant bit of each 24-bit pixel can be changed without greatly affecting, the quality of the image. The result is that you can hide a 130-kB message in a single, digital snapshot. There are now a number of software packages available that take, this type of approach to steganography., Steganography has a number of drawbacks when compared to encryption., It requires a lot of overhead to hide a relatively few bits of information, although, using a scheme like that proposed in the preceding paragraph may make it more, effective. Also, once the system is discovered, it becomes virtually worthless. This, problem, too, can be overcome if the insertion method depends on some sort of key, (e.g., see Problem 3.22). Alternatively, a message can be first encrypted and then, hidden using steganography., The advantage of steganography is that it can be employed by parties who, have something to lose should the fact of their secret communication (not necessarily the content) be discovered. Encryption flags traffic as important or secret or may, identify the sender or receiver as someone with something to hide.
Page 113 :
112, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , 3.6 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, block cipher, brute-force attack, Caesar cipher, cipher, ciphertext, computationally secure, conventional encryption, cryptanalysis, cryptographic system, cryptography, , cryptology, deciphering, decryption, digram, enciphering, encryption, Hill cipher, monoalphabetic cipher, one-time pad, plaintext, , Playfair cipher, polyalphabetic cipher, rail fence cipher, single-key encryption, steganography, stream cipher, symmetric encryption, transposition cipher, unconditionally secure, Vigenère cipher, , Review Questions, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, 3.14, , Describe the main requirements for the secure use of symmetric encryption., What are the two basic functions used in encryption algorithms?, Differentiate between secret-key encryption and public-key encryption., What is the difference between a block cipher and a stream cipher?, What are the two general approaches to attacking a cipher?, List and briefly define types of cryptanalytic attacks based on what is known to the, attacker., What is the difference between an unconditionally secure cipher and a computationally secure cipher?, Why is the Caesar cipher substitution technique vulnerable to a brute-force cryptanalysis?, How much key space is available when a monoalphabetic substitution cipher is used, to replace plaintext with ciphertext?, What is the drawback of a Playfair cipher?, What is the difference between a monoalphabetic cipher and a polyalphabetic cipher?, What are two problems with the one-time pad?, What is a transposition cipher?, What are the drawbacks of Steganography?, , Problems, 3.1, , A generalization of the Caesar cipher, known as the affine Caesar cipher, has the following form: For each plaintext letter p, substitute the ciphertext letter C:, C = E([a, b], p) = (ap + b) mod 26, A basic requirement of any encryption algorithm is that it be one-to-one. That is, if, p ≠ q, then E(k, p) ≠ E(k, q). Otherwise, decryption is impossible, because more, than one plaintext character maps into the same ciphertext character. The affine, Caesar cipher is not one-to-one for all values of a. For example, for a = 2 and b = 3,, then E([a, b], 0) = E([a, b], 13) = 3., a. Are there any limitations on the value of b? Explain why or why not., b. Determine which values of a are not allowed.
Page 115 :
114, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , 3.7, , Although Watson was puzzled, Holmes was able immediately to deduce the type of, cipher. Can you?, This problem uses a real-world example, from an old U.S. Special Forces manual, (public domain). The document, filename SpecialForces.pdf, is available at box.com/, Crypto7e., a. Using the two keys (memory words) cryptographic and network security, encrypt, the following message:, Be at the third pillar from the left outside the lyceum theatre tonight at seven., If you are distrustful bring two friends., Make reasonable assumptions about how to treat redundant letters and excess, letters in the memory words and how to treat spaces and punctuation. Indicate, what your assumptions are. Note: The message is from the Sherlock Holmes novel,, The Sign of Four., b. Decrypt the ciphertext. Show your work., c. Comment on when it would be appropriate to use this technique and what its, advantages are., , 3.8, , A disadvantage of the general monoalphabetic cipher is that both sender and receiver, must commit the permuted cipher sequence to memory. A common technique for, avoiding this is to use a keyword from which the cipher sequence can be generated. For example, using the keyword CRYPTO, write out the keyword followed by, unused letters in normal order and match this against the plaintext letters:, plain: a b c d e f g h i j k l m n o p q r s t u v w x y z, cipher: C R Y P T O A B D E F G H I J K L M N Q S U V W X Z, If it is felt that this process does not produce sufficient mixing, write the remaining letters on successive lines and then generate the sequence by reading down the, columns:, C, A, H, N, X, , R, B, I, Q, Z, , Y, D, J, S, , P, E, K, U, , T, F, L, V, , O, G, M, W, , This yields the sequence:, C A H N X R B I Q Z Y D J S P E K U T F L V O G M W, , 3.9, , Such a system is used in the example in Section 3.2 (the one that begins “it was, disclosed yesterday”). Determine the keyword., When the PT-109 American patrol boat, under the command of Lieutenant John F., Kennedy, was sunk by a Japanese destroyer, a message was received at an Australian, wireless station in Playfair code:, KXJEY, KREHE, BOTEI, GDSON, , UREBE, GOYFI, ZONTX, SXBOU, , ZWEHE, WTTTU, BYBNT, YWRHE, , WRYTU, OLKSY, GONEY, BAAHY, , HEYFS, CAJPO, CUZWR, USEDQ, , The key used was royal new zealand navy. Decrypt the message. Translate TT into tt.
Page 116 :
3.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 3.10, , 3.11, , 115, , a. Construct a Playfair matrix with the key algorithm., b. Construct a Playfair matrix with the key cryptography. Make a reasonable assumption about how to treat redundant letters in the key., a. Using this Playfair matrix:, J/K, , C, , D, , E, , F, , U, , N, , P, , Q, , S, , Z, , V, , W, , X, , Y, , R, , A, , L, , G, , O, , B, , I, , T, , H, , M, , Encrypt this message:, I only regret that I have but one life to give for my country., , 3.12, , 3.13, 3.14, , Note: This message is by Nathan Hale, a soldier in the American Revolutionary War., b. Repeat part (a) using the Playfair matrix from Problem 3.10a., c. How do you account for the results of this problem? Can you generalize your, conclusion?, a. How many possible keys does the Playfair cipher have? Ignore the fact that, some keys might produce identical encryption results. Express your answer as an, approximate power of 2., b. Now take into account the fact that some Playfair keys produce the same encryption results. How many effectively unique keys does the Playfair cipher have?, What substitution system results when we use a 1 * 25 Playfair matrix?, a. Encrypt the message “meet me at the usual place at ten rather than eight o clock”, using the Hill cipher with the key ¢, , 3.15, , 3.16, , 7, 2, , 3, ≤. Show your calculations and the result., 5, , b. Show the calculations for the corresponding decryption of the ciphertext to, recover the original plaintext., We have shown that the Hill cipher succumbs to a known plaintext attack if sufficient, plaintext–ciphertext pairs are provided. It is even easier to solve the Hill cipher if a, chosen plaintext attack can be mounted. Describe such an attack., a b, ≤ requires that (ad - bc), c d, is relatively prime to 26; that is, the only common positive integer factor of (ad - bc), and 26 is 1. Thus, if (ad - bc) = 13 or is even, the matrix is not allowed. Determine, the number of different (good) keys there are for a 2 * 2 Hill cipher without counting them one by one, using the following steps:, a. Find the number of matrices whose determinant is even because one or both rows, are even. (A row is “even” if both entries in the row are even.), b. Find the number of matrices whose determinant is even because one or both columns are even. (A column is “even” if both entries in the column are even.), c. Find the number of matrices whose determinant is even because all of the entries, are odd., d. Taking into account overlaps, find the total number of matrices whose determinant is even., e. Find the number of matrices whose determinant is a multiple of 13 because the, first column is a multiple of 13., It can be shown that the Hill cipher with the matrix ¢
Page 117 :
116, , CHAPTER 3 / CLASSICAL ENCRYPTION TECHNIQUES, , 3.17, , f. Find the number of matrices whose determinant is a multiple of 13 where, the first column is not a multiple of 13 but the second column is a multiple of the first modulo 13., g. Find the total number of matrices whose determinant is a multiple of 13., h. Find the number of matrices whose determinant is a multiple of 26, because they fit cases parts (a) and (e), (b) and (e), (c) and (e), (a) and, (f), and so on., i. Find the total number of matrices whose determinant is neither a multiple of 2 nor a multiple of 13., Calculate the determinant mod 26 of, 23, a. ¢, 13, , 3.18, , 3.20, , 13, 7, 14, , 25, 18 ≥, 12, , Determine the inverse mod 26 of, a. ¢, , 3.19, , 21, b. £ 5, 3, , 5, ≤, 7, , 2, 1, , 6, b. £ 13, 20, , 3, ≤, 22, , 24, 16, 17, , 1, 10 ≥, 15, , Using the Vigenère cipher, encrypt the word “cryptographic” using the word, “eng”., This problem explores the use of a one-time pad version of the Vigenère, cipher. In this scheme, the key is a stream of random numbers between 0, and 26. For example, if the key is 3 19 5 . . . , then the first letter of plaintext, is encrypted with a shift of 3 letters, the second with a shift of 19 letters, the, third with a shift of 5 letters, and so on., a. Encrypt the plaintext sendmoremoney with the key stream, 3 11 5 7 17 21 0 11 14 8 7 13 9, , 3.21, 3.22, , b. Using the ciphertext produced in part (a), find a key so that the ciphertext decrypts to the plaintext cashnotneeded., What is the message embedded in Figure 3.9?, In one of Dorothy Sayers’s mysteries, Lord Peter is confronted with the, message shown in Figure 3.10. He also discovers the key to the message,, which is a sequence of integers:, 787656543432112343456567878878765654, 3432112343456567878878765654433211234, a. Decrypt the message. Hint: What is the largest integer value?, b. If the algorithm is known but not the key, how secure is the scheme?, c. If the key is known but not the algorithm, how secure is the scheme?, , I thought to see the fairies in the fields, but I saw only the evil elephants with their black, backs. Woe! how that sight awed me! The elves danced all around and about while I heard, voices calling clearly. Ah! how I tried to see—throw off the ugly cloud—but no blind eye, of a mortal was permitted to spy them. So then came minstrels, having gold trumpets, harps, and drums. These played very loudly beside me, breaking that spell. So the dream vanished,, whereat I thanked Heaven. I shed many tears before the thin moon rose up, frail and faint as, a sickle of straw. Now though the Enchanter gnash his teeth vainly, yet shall he return as the, Spring returns. Oh, wretched man! Hell gapes, Erebus now lies open. The mouths of Death, wait on thy end., Figure 3.10 A Puzzle for Lord Peter
Page 118 :
3.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 117, , Programming Problems, 3.23, 3.24, 3.25, , 3.26, , 3.27, 3.28, , Write a program that can encrypt and decrypt using the general Caesar, cipher, also known as an additive cipher., Write a program that can encrypt and decrypt using the affine cipher, described in Problem 3.1., Write a program that can perform a letter frequency attack on an additive, cipher without human intervention. Your software should produce possible, plaintexts in rough order of likelihood. It would be good if your user interface allowed the user to specify “give me the top 10 possible plaintexts.”, Write a program that can perform a letter frequency attack on any monoalphabetic substitution cipher without human intervention. Your software, should produce possible plaintexts in rough order of likelihood. It would, be good if your user interface allowed the user to specify “give me the top, 10 possible plaintexts.”, Create software that can encrypt and decrypt using a 2 * 2 Hill cipher., Create software that can perform a fast known plaintext attack on a Hill cipher,, given the dimension m. How fast are your algorithms, as a function of m?
Page 119 :
CHAPTER, , Block Ciphers and the Data, Encryption Standard, 4.1, , Traditional Block Cipher Structure, Stream Ciphers and Block Ciphers, Motivation for the Feistel Cipher Structure, The Feistel Cipher, , 4.2, , The Data Encryption Standard, DES Encryption, DES Decryption, , 4.3, , A DES Example, Results, The Avalanche Effect, , 4.4, , The Strength of DES, The Use of 56-Bit Keys, The Nature of the DES Algorithm, Timing Attacks, , 4.5, , Block Cipher Design Principles, Number of Rounds, Design of Function F, Key Schedule Algorithm, , 4.6, , Key Terms, Review Questions, and Problems, , 118, Hiva-Network.Com
Page 120 :
4.1 / TRADITIONAL BLOCK CIPHER STRUCTURE, , 119, , LEARNING OBJECTIVES, After studying this chapter, you should be able to, ◆ Understand the distinction between stream ciphers and block ciphers., ◆ Present an overview of the Feistel cipher and explain how decryption is, the inverse of encryption., ◆ Present an overview of Data Encryption Standard (DES)., ◆ Explain the concept of the avalanche effect., ◆ Discuss the cryptographic strength of DES., ◆ Summarize the principal block cipher design principles., , The objective of this chapter is to illustrate the principles of modern symmetric, ciphers. For this purpose, we focus on the most widely used symmetric cipher: the Data, Encryption Standard (DES). Although numerous symmetric ciphers have been developed since the introduction of DES, and although it is destined to be replaced by the, Advanced Encryption Standard (AES), DES remains the most important such algorithm. Furthermore, a detailed study of DES provides an understanding of the principles used in other symmetric ciphers., This chapter begins with a discussion of the general principles of symmetric block, ciphers, which are the principal type of symmetric ciphers studied in this book. The, other form of symmetric ciphers, stream ciphers, are discussed in Chapter 8. Next, we, cover full DES. Following this look at a specific algorithm, we return to a more general, discussion of block cipher design., Compared to public-key ciphers, such as RSA, the structure of DES and most, symmetric ciphers is very complex and cannot be explained as easily as RSA and similar algorithms. Accordingly, the reader may wish to begin with a simplified version of, DES, which is described in Appendix G. This version allows the reader to perform, encryption and decryption by hand and gain a good understanding of the working of, the algorithm details. Classroom experience indicates that a study of this simplified, version enhances understanding of DES.1, , 4.1 TRADITIONAL BLOCK CIPHER STRUCTURE, Several important symmetric block encryption algorithms in current use are based, on a structure referred to as a Feistel block cipher [FEIS73]. For that reason, it is, important to examine the design principles of the Feistel cipher. We begin with a, comparison of stream ciphers and block ciphers. Then we discuss the motivation for, the Feistel block cipher structure. Finally, we discuss some of its implications., , 1, , However, you may safely skip Appendix G, at least on a first reading. If you get lost or bogged down in, the details of DES, then you can go back and start with simplified DES.
Page 121 :
120, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , Stream Ciphers and Block Ciphers, A stream cipher is one that encrypts a digital data stream one bit or one byte at a, time. Examples of classical stream ciphers are the autokeyed Vigenère cipher and, the Vernam cipher. In the ideal case, a one-time pad version of the Vernam cipher, would be used (Figure 3.7), in which the keystream (ki) is as long as the plaintext bit, stream (pi). If the cryptographic keystream is random, then this cipher is unbreakable, by any means other than acquiring the keystream. However, the keystream must be, provided to both users in advance via some independent and secure channel. This, introduces insurmountable logistical problems if the intended data traffic is very large., Accordingly, for practical reasons, the bit-stream generator must be implemented as an algorithmic procedure, so that the cryptographic bit stream can be, produced by both users. In this approach (Figure 4.1a), the bit-stream generator is, a key-controlled algorithm and must produce a bit stream that is cryptographically, strong. That is, it must be computationally impractical to predict future portions of, the bit stream based on previous portions of the bit stream. The two users need only, share the generating key, and each can produce the keystream., A block cipher is one in which a block of plaintext is treated as a whole and, used to produce a ciphertext block of equal length. Typically, a block size of 64 or, , Key, (K), , Bit-stream, generation, algorithm, , Key, (K), , ki, Plaintext, (pi), , Bit-stream, generation, algorithm, ki, Plaintext, (pi), , Ciphertext, (ci), ENCRYPTION, , DECRYPTION, , (a) Stream cipher using algorithmic bit-stream generator, , Key, (K), , b bits, , b bits, , Plaintext, , Ciphertext, , Encryption, algorithm, , Key, (K), , Ciphertext, , Plaintext, , b bits, , b bits, , (b) Block cipher, , Figure 4.1, , Decryption, algorithm, , Stream Cipher and Block Cipher
Page 122 :
4.1 / TRADITIONAL BLOCK CIPHER STRUCTURE, , 121, , 128 bits is used. As with a stream cipher, the two users share a symmetric encryption, key (Figure 4.1b). Using some of the modes of operation explained in Chapter 7, a, block cipher can be used to achieve the same effect as a stream cipher., Far more effort has gone into analyzing block ciphers. In general, they seem, applicable to a broader range of applications than stream ciphers. The vast majority, of network-based symmetric cryptographic applications make use of block ciphers., Accordingly, the concern in this chapter, and in our discussions throughout the, book of symmetric encryption, will primarily focus on block ciphers., , Motivation for the Feistel Cipher Structure, A block cipher operates on a plaintext block of n bits to produce a ciphertext block, of n bits. There are 2n possible different plaintext blocks and, for the encryption, to be reversible (i.e., for decryption to be possible), each must produce a unique, ciphertext block. Such a transformation is called reversible, or nonsingular. The following examples illustrate nonsingular and singular transformations for n = 2., Reversible Mapping, , Irreversible Mapping, , Plaintext, , Ciphertext, , Plaintext, , Ciphertext, , 00, , 11, , 00, , 11, , 01, , 10, , 01, , 10, , 10, , 00, , 10, , 01, , 11, , 01, , 11, , 01, , In the latter case, a ciphertext of 01 could have been produced by one of two plaintext blocks. So if we limit ourselves to reversible mappings, the number of different, transformations is 2n!.2, Figure 4.2 illustrates the logic of a general substitution cipher for n = 4., A 4-bit input produces one of 16 possible input states, which is mapped by the substitution cipher into a unique one of 16 possible output states, each of which is represented by 4 ciphertext bits. The encryption and decryption mappings can be defined, by a tabulation, as shown in Table 4.1. This is the most general form of block cipher, and can be used to define any reversible mapping between plaintext and ciphertext., Feistel refers to this as the ideal block cipher, because it allows for the maximum, number of possible encryption mappings from the plaintext block [FEIS75]., But there is a practical problem with the ideal block cipher. If a small block, size, such as n = 4, is used, then the system is equivalent to a classical substitution, cipher. Such systems, as we have seen, are vulnerable to a statistical analysis of the, plaintext. This weakness is not inherent in the use of a substitution cipher but rather, results from the use of a small block size. If n is sufficiently large and an arbitrary, reversible substitution between plaintext and ciphertext is allowed, then the statistical characteristics of the source plaintext are masked to such an extent that this type, of cryptanalysis is infeasible., 2, The reasoning is as follows: For the first plaintext, we can choose any of 2n ciphertext blocks. For the, second plaintext, we choose from among 2n - 1 remaining ciphertext blocks, and so on.
Page 123 :
122, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, 4-bit input, , 0, , 1, , 2, , 3, , 4, , 5, , 0, , 1, , 2, , 3, , 4, , 5, , 4 to 16 decoder, 6, 7, 8, 9, , 6, 7, 8, 9, 16 to 4 encoder, , 10, , 11, , 12, , 13, , 14, , 15, , 10, , 11, , 12, , 13, , 14, , 15, , 4-bit output, , Figure 4.2 General n-bit-n-bit Block Substitution (shown with n = 4), , An arbitrary reversible substitution cipher (the ideal block cipher) for a large, block size is not practical, however, from an implementation and performance, point of view. For such a transformation, the mapping itself constitutes the key., Consider again Table 4.1, which defines one particular reversible mapping from, Table 4.1, , Encryption and Decryption Tables for Substitution Cipher of Figure 4.2, , Plaintext, , Ciphertext, , Ciphertext, , Plaintext, , 0000, , 1110, , 0000, , 1110, , 0001, , 0100, , 0001, , 0011, , 0010, , 1101, , 0010, , 0100, , 0011, , 0001, , 0011, , 1000, , 0100, , 0010, , 0100, , 0001, , 0101, , 1111, , 0101, , 1100, , 0110, , 1011, , 0110, , 1010, , 0111, , 1000, , 0111, , 1111, , 1000, , 0011, , 1000, , 0111, , 1001, , 1010, , 1001, , 1101, , 1010, , 0110, , 1010, , 1001, , 1011, , 1100, , 1011, , 0110, , 1100, , 0101, , 1100, , 1011, , 1101, , 1001, , 1101, , 0010, , 1110, , 0000, , 1110, , 0000, , 1111, , 0111, , 1111, , 0101
Page 124 :
4.1 / TRADITIONAL BLOCK CIPHER STRUCTURE, , 123, , plaintext to ciphertext for n = 4. The mapping can be defined by the entries in the, second column, which show the value of the ciphertext for each plaintext block., This, in essence, is the key that determines the specific mapping from among all, possible mappings. In this case, using this straightforward method of defining the, key, the required key length is (4 bits) * (16 rows) = 64 bits. In general, for an, n-bit ideal block cipher, the length of the key defined in this fashion is n * 2n bits., For a 64-bit block, which is a desirable length to thwart statistical attacks, the, required key length is 64 * 264 = 270 ≈ 1021 bits., In considering these difficulties, Feistel points out that what is needed is an, approximation to the ideal block cipher system for large n, built up out of components that are easily realizable [FEIS75]. But before turning to Feistel’s approach,, let us make one other observation. We could use the general block substitution, cipher but, to make its implementation tractable, confine ourselves to a subset of, the 2n! possible reversible mappings. For example, suppose we define the mapping, in terms of a set of linear equations. In the case of n = 4, we have, y1 = k11x1 + k12x2 + k13x3 + k14x4, y2 = k21x1 + k22x2 + k23x3 + k24x4, y3 = k31x1 + k32x2 + k33x3 + k34x4, y4 = k41x1 + k42x2 + k43x3 + k44x4, where the xi are the four binary digits of the plaintext block, the yi are the four binary digits of the ciphertext block, the kij are the binary coefficients, and arithmetic, is mod 2. The key size is just n2, in this case 16 bits. The danger with this kind of formulation is that it may be vulnerable to cryptanalysis by an attacker that is aware of, the structure of the algorithm. In this example, what we have is essentially the Hill, cipher discussed in Chapter 3, applied to binary data rather than characters. As we, saw in Chapter 3, a simple linear system such as this is quite vulnerable., , The Feistel Cipher, Feistel proposed [FEIS73] that we can approximate the ideal block cipher by utilizing the concept of a product cipher, which is the execution of two or more simple, ciphers in sequence in such a way that the final result or product is cryptographically stronger than any of the component ciphers. The essence of the approach is, to develop a block cipher with a key length of k bits and a block length of n bits,, allowing a total of 2k possible transformations, rather than the 2n! transformations, available with the ideal block cipher., In particular, Feistel proposed the use of a cipher that alternates substitutions, and permutations, where these terms are defined as follows:, ■, ■, , Substitution: Each plaintext element or group of elements is uniquely replaced, by a corresponding ciphertext element or group of elements., Permutation: A sequence of plaintext elements is replaced by a permutation, of that sequence. That is, no elements are added or deleted or replaced in the, sequence, rather the order in which the elements appear in the sequence is, changed.
Page 125 :
124, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , In fact, Feistel’s is a practical application of a proposal by Claude Shannon, to develop a product cipher that alternates confusion and diffusion functions, [SHAN49].3 We look next at these concepts of diffusion and confusion and then, present the Feistel cipher. But first, it is worth commenting on this remarkable fact:, The Feistel cipher structure, which dates back over a quarter century and which, in, turn, is based on Shannon’s proposal of 1945, is the structure used by a number of, significant symmetric block ciphers currently in use. In particular, the Feistel structure is used for Triple Data Encryption Algorithm (TDEA), which is one of the two, encryption algorithms (along with AES), approved for general use by the National, Institute of Standards and Technology (NIST). The Feistel structure is also used for, several schemes for format-preserving encryption, which have recently come into, prominence. In addition, the Camellia block cipher is a Feistel structure; it is one, of the possible symmetric ciphers in TLS and a number of other Internet security, protocols. Both TDEA and format-preserving encryption are covered in Chapter 7., DIFFUSION AND CONFUSION The terms diffusion and confusion were introduced by, Claude Shannon to capture the two basic building blocks for any cryptographic system [SHAN49]. Shannon’s concern was to thwart cryptanalysis based on statistical analysis. The reasoning is as follows. Assume the attacker has some knowledge, of the statistical characteristics of the plaintext. For example, in a human-readable, message in some language, the frequency distribution of the various letters may be, known. Or there may be words or phrases likely to appear in the message (probable, words). If these statistics are in any way reflected in the ciphertext, the cryptanalyst, may be able to deduce the encryption key, part of the key, or at least a set of keys, likely to contain the exact key. In what Shannon refers to as a strongly ideal cipher,, all statistics of the ciphertext are independent of the particular key used. The arbitrary substitution cipher that we discussed previously (Figure 4.2) is such a cipher,, but as we have seen, it is impractical.4, Other than recourse to ideal systems, Shannon suggests two methods for, frustrating statistical cryptanalysis: diffusion and confusion. In diffusion, the statistical structure of the plaintext is dissipated into long-range statistics of the, ciphertext. This is achieved by having each plaintext digit affect the value of many, ciphertext digits; generally, this is equivalent to having each ciphertext digit be, affected by many plaintext digits. An example of diffusion is to encrypt a message, M = m1, m2, m3, c of characters with an averaging operation:, k, , yn = ¢ a mn + i ≤ mod 26, i=1, , 3, , The paper is available at box.com/Crypto7e. Shannon’s 1949 paper appeared originally as a classified, report in 1945. Shannon enjoys an amazing and unique position in the history of computer and information science. He not only developed the seminal ideas of modern cryptography but is also responsible for, inventing the discipline of information theory. Based on his work in information theory, he developed, a formula for the capacity of a data communications channel, which is still used today. In addition, he, founded another discipline, the application of Boolean algebra to the study of digital circuits; this last he, managed to toss off as a master’s thesis., , 4, , Appendix F expands on Shannon’s concepts concerning measures of secrecy and the security of cryptographic algorithms.
Page 126 :
4.1 / TRADITIONAL BLOCK CIPHER STRUCTURE, , 125, , adding k successive letters to get a ciphertext letter yn. One can show that the statistical structure of the plaintext has been dissipated. Thus, the letter frequencies in, the ciphertext will be more nearly equal than in the plaintext; the digram frequencies will also be more nearly equal, and so on. In a binary block cipher, diffusion can, be achieved by repeatedly performing some permutation on the data followed by, applying a function to that permutation; the effect is that bits from different positions in the original plaintext contribute to a single bit of ciphertext.5, Every block cipher involves a transformation of a block of plaintext into a, block of ciphertext, where the transformation depends on the key. The mechanism, of diffusion seeks to make the statistical relationship between the plaintext and, ciphertext as complex as possible in order to thwart attempts to deduce the key. On, the other hand, confusion seeks to make the relationship between the statistics of, the ciphertext and the value of the encryption key as complex as possible, again to, thwart attempts to discover the key. Thus, even if the attacker can get some handle, on the statistics of the ciphertext, the way in which the key was used to produce that, ciphertext is so complex as to make it difficult to deduce the key. This is achieved by, the use of a complex substitution algorithm. In contrast, a simple linear substitution, function would add little confusion., As [ROBS95b] points out, so successful are diffusion and confusion in capturing the essence of the desired attributes of a block cipher that they have become the, cornerstone of modern block cipher design., FEISTEL CIPHER STRUCTURE The left-hand side of Figure 4.3 depicts the encryption, structure proposed by Feistel. The inputs to the encryption algorithm are a plaintext, block of length 2w bits and a key K. The plaintext block is divided into two halves,, LE0 and RE0. The two halves of the data pass through n rounds of processing and, then combine to produce the ciphertext block. Each round i has as inputs LEi - 1 and, REi - 1 derived from the previous round, as well as a subkey Ki derived from the overall K. In general, the subkeys Ki are different from K and from each other. In Figure, 4.3, 16 rounds are used, although any number of rounds could be implemented., All rounds have the same structure. A substitution is performed on the left, half of the data. This is done by applying a round function F to the right half of the, data and then taking the exclusive-OR of the output of that function and the left, half of the data. The round function has the same general structure for each round, but is parameterized by the round subkey Ki. Another way to express this is to say, that F is a function of right-half block of w bits and a subkey of y bits, which produces an output value of length w bits: F(REi, Ki + 1). Following this substitution, a, permutation is performed that consists of the interchange of the two halves of the, data.6 This structure is a particular form of the substitution-permutation network, (SPN) proposed by Shannon., , 5, , Some books on cryptography equate permutation with diffusion. This is incorrect. Permutation, by itself,, does not change the statistics of the plaintext at the level of individual letters or permuted blocks. For example, in DES, the permutation swaps two 32-bit blocks, so statistics of strings of 32 bits or less are preserved., , 6, , The final round is followed by an interchange that undoes the interchange that is part of the final round., One could simply leave both interchanges out of the diagram, at the sacrifice of some consistency of presentation. In any case, the effective lack of a swap in the final round is done to simplify the implementation of the decryption process, as we shall see.
Page 128 :
4.1 / TRADITIONAL BLOCK CIPHER STRUCTURE, ■, , ■, , ■, ■, , 127, , Key size: Larger key size means greater security but may decrease encryption/, decryption speed. The greater security is achieved by greater resistance to, brute-force attacks and greater confusion. Key sizes of 64 bits or less are now, widely considered to be inadequate, and 128 bits has become a common size., Number of rounds: The essence of the Feistel cipher is that a single round, offers inadequate security but that multiple rounds offer increasing security., A typical size is 16 rounds., Subkey generation algorithm: Greater complexity in this algorithm should, lead to greater difficulty of cryptanalysis., Round function F: Again, greater complexity generally means greater resistance to cryptanalysis., , There are two other considerations in the design of a Feistel cipher:, ■, , ■, , Fast software encryption/decryption: In many cases, encryption is embedded, in applications or utility functions in such a way as to preclude a hardware implementation. Accordingly, the speed of execution of the algorithm becomes a, concern., Ease of analysis: Although we would like to make our algorithm as difficult as, possible to cryptanalyze, there is great benefit in making the algorithm easy, to analyze. That is, if the algorithm can be concisely and clearly explained, it is, easier to analyze that algorithm for cryptanalytic vulnerabilities and therefore, develop a higher level of assurance as to its strength. DES, for example, does, not have an easily analyzed functionality., , FEISTEL DECRYPTION ALGORITHM The process of decryption with a Feistel cipher, is essentially the same as the encryption process. The rule is as follows: Use the, ciphertext as input to the algorithm, but use the subkeys Ki in reverse order. That, is, use Kn in the first round, Kn - 1 in the second round, and so on, until K1 is used in, the last round. This is a nice feature, because it means we need not implement two, different algorithms; one for encryption and one for decryption., To see that the same algorithm with a reversed key order produces the correct result, Figure 4.3 shows the encryption process going down the left-hand side, and the decryption process going up the right-hand side for a 16-round algorithm., For clarity, we use the notation LEi and REi for data traveling through the encryption algorithm and LDi and RDi for data traveling through the decryption algorithm. The diagram indicates that, at every round, the intermediate value of the, decryption process is equal to the corresponding value of the encryption process, with the two halves of the value swapped. To put this another way, let the output, of the ith encryption round be LEi ‘REi (LEi concatenated with REi). Then the corresponding output of the (16 - i)th decryption round is REi ‘LEi or, equivalently,, LD16 - i ‘RD16 - i., Let us walk through Figure 4.3 to demonstrate the validity of the preceding, assertions. After the last iteration of the encryption process, the two halves of the, output are swapped, so that the ciphertext is RE16 ‘LE16. The output of that round, is the ciphertext. Now take that ciphertext and use it as input to the same algorithm., The input to the first round is RE16 ‘LE16, which is equal to the 32-bit swap of the, output of the sixteenth round of the encryption process., , Hiva-Network.Com
Page 129 :
128, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , Now we would like to show that the output of the first round of the decryption, process is equal to a 32-bit swap of the input to the sixteenth round of the encryption process. First, consider the encryption process. We see that, LE16 = RE15, RE16 = LE15 ⊕ F(RE15, K16), On the decryption side,, LD1 = RD0 = LE16 = RE15, RD1 = LD0 ⊕ F(RD0, K16), = RE16 ⊕ F(RE15, K16), = [LE15 ⊕ F(RE15, K16)] ⊕ F(RE15, K16), The XOR has the following properties:, [A ⊕ B] ⊕ C = A ⊕ [B ⊕ C], D⊕D = 0, E⊕0 = E, Thus, we have LD1 = RE15 and RD1 = LE15. Therefore, the output of the first, round of the decryption process is RE15 ‘LE15, which is the 32-bit swap of the input, to the sixteenth round of the encryption. This correspondence holds all the way, through the 16 iterations, as is easily shown. We can cast this process in general, terms. For the ith iteration of the encryption algorithm,, LEi = REi - 1, REi = LEi - 1 ⊕ F(REi - 1, Ki), Rearranging terms:, REi - 1 = LEi, LEi - 1 = REi ⊕ F(REi - 1, Ki) = REi ⊕ F(LEi, Ki), Thus, we have described the inputs to the ith iteration as a function of the outputs, and, these equations confirm the assignments shown in the right-hand side of Figure 4.3., Finally, we see that the output of the last round of the decryption process is, RE0 ‘LE0. A 32-bit swap recovers the original plaintext, demonstrating the validity, of the Feistel decryption process., Note that the derivation does not require that F be a reversible function. To, see this, take a limiting case in which F produces a constant output (e.g., all ones), regardless of the values of its two arguments. The equations still hold., To help clarify the preceding concepts, let us look at a specific example, (Figure 4.4 and focus on the fifteenth round of encryption, corresponding to the second round of decryption. Suppose that the blocks at each stage are 32 bits (two 16-bit, halves) and that the key size is 24 bits. Suppose that at the end of encryption round, fourteen, the value of the intermediate block (in hexadecimal) is DE7F03A6. Then, LE14 = DE7F and RE14 = 03A6. Also assume that the value of K15 is 12DE52., After round 15, we have LE15 = 03A6 and RE15 = F(03A6, 12DE52) ⊕ DE7F.
Page 130 :
4.2 / THE DATA ENCRYPTION STANDARD, Encryption round, , F(03A6, 12DE52), [F(03A6, 12DE52) DE7F], = DE7F, 03A6, , 03A6, F, , 12DE52, F, , 03A6, , Figure 4.4, , Decryption round, , F(03A6, 12DE52), , DE7F, , F(03A6, 12DE52), , DE7F, , 12DE52, , Round 2, , Round 15, , DE7F, , 129, , 03A6, , Feistel Example, , Now let’s look at the decryption. We assume that LD1 = RE15 and, RD1 = LE15, as shown in Figure 4.3, and we want to demonstrate that LD2 = RE14, and RD2 = LE14. So, we start with LD1 = F(03A6, 12DE52) ⊕ DE7F and, RD1 = 03A6. Then, from Figure 4.3, LD2 = 03A6 = RE14 and RD2 =, F(03A6, 12DE52) ⊕ [F(03A6, 12DE52) ⊕ DE7F] = DE7F = LE14., , 4.2 THE DATA ENCRYPTION STANDARD, Until the introduction of the Advanced Encryption Standard (AES) in 2001, the, Data Encryption Standard (DES) was the most widely used encryption scheme., DES was issued in 1977 by the National Bureau of Standards, now the National, Institute of Standards and Technology (NIST), as Federal Information Processing, Standard 46 (FIPS PUB 46). The algorithm itself is referred to as the Data, Encryption Algorithm (DEA).7 For DEA, data are encrypted in 64-bit blocks using, a 56-bit key. The algorithm transforms 64-bit input in a series of steps into a 64-bit, output. The same steps, with the same key, are used to reverse the encryption., Over the years, DES became the dominant symmetric encryption algorithm,, especially in financial applications. In 1994, NIST reaffirmed DES for federal use, for another five years; NIST recommended the use of DES for applications other, than the protection of classified information. In 1999, NIST issued a new version, of its standard (FIPS PUB 46-3) that indicated that DES should be used only, for legacy systems and that triple DES (which in essence involves repeating the, DES algorithm three times on the plaintext using two or three different keys to, produce the ciphertext) be used. We study triple DES in Chapter 7. Because the, underlying encryption and decryption algorithms are the same for DES and triple, DES, it remains important to understand the DES cipher. This section provides an, overview.For the interested reader, Appendix S provides further detail., 7, The terminology is a bit confusing. Until recently, the terms DES and DEA could be used interchangeably. However, the most recent edition of the DES document includes a specification of the DEA, described here plus the triple DEA (TDEA) described in Chapter 7. Both DEA and TDEA are part of, the Data Encryption Standard. Further, until the recent adoption of the official term TDEA, the triple, DEA algorithm was typically referred to as triple DES and written as 3DES. For the sake of convenience,, we will use the term 3DES.
Page 131 :
130, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , DES Encryption, The overall scheme for DES encryption is illustrated in Figure 4.5. As with any, encryption scheme, there are two inputs to the encryption function: the plaintext to, be encrypted and the key. In this case, the plaintext must be 64 bits in length and the, key is 56 bits in length.8, Looking at the left-hand side of the figure, we can see that the processing, of the plaintext proceeds in three phases. First, the 64-bit plaintext passes through, an initial permutation (IP) that rearranges the bits to produce the permuted input., , 64-bit plaintext, , 64-bit key, , %%%%%%%%%, , %%%%%%%%%, , Initial permutation, , Permuted choice 1, , 64, Round 1, , 56, K1, , 48, , K2, , 48, , Permuted choice 2, , 56, , Left circular shift, , 64, Round 2, , Round 16, , 56, , K16 48, , Permuted choice 2, , Permuted choice 2, , 56, , 56, , Left circular shift, , Left circular shift, , 32-bit swap, 64 bits, Inverse initial, permutation, %%%%%%%%%, 64-bit ciphertext, , Figure 4.5, , General Depiction of DES Encryption Algorithm, , 8, Actually, the function expects a 64-bit key as input. However, only 56 of these bits are ever used; the, other 8 bits can be used as parity bits or simply set arbitrarily.
Page 132 :
4.3 / A DES EXAMPLE, , 131, , This is followed by a phase consisting of sixteen rounds of the same function, which, involves both permutation and substitution functions. The output of the last (sixteenth) round consists of 64 bits that are a function of the input plaintext and the, key. The left and right halves of the output are swapped to produce the preoutput., Finally, the preoutput is passed through a permutation [IP -1] that is the inverse of, the initial permutation function, to produce the 64-bit ciphertext. With the exception of the initial and final permutations, DES has the exact structure of a Feistel, cipher, as shown in Figure 4.3., The right-hand portion of Figure 4.5 shows the way in which the 56-bit key is, used. Initially, the key is passed through a permutation function. Then, for each of, the sixteen rounds, a subkey (Ki) is produced by the combination of a left circular, shift and a permutation. The permutation function is the same for each round, but a, different subkey is produced because of the repeated shifts of the key bits., , DES Decryption, As with any Feistel cipher, decryption uses the same algorithm as encryption, except, that the application of the subkeys is reversed. Additionally, the initial and final, permutations are reversed., , 4.3 A DES EXAMPLE, We now work through an example and consider some of its implications. Although, you are not expected to duplicate the example by hand, you will find it informative, to study the hex patterns that occur from one step to the next., For this example, the plaintext is a hexadecimal palindrome. The plaintext,, key, and resulting ciphertext are as follows:, Plaintext:, , 02468aceeca86420, , Key:, , 0f1571c947d9e859, , Ciphertext:, , da02ce3a89ecac3b, , Results, Table 4.2 shows the progression of the algorithm. The first row shows the 32-bit, values of the left and right halves of data after the initial permutation. The next 16, rows show the results after each round. Also shown is the value of the 48-bit subkey, generated for each round. Note that Li = Ri - 1. The final row shows the left- and, right-hand values after the inverse initial permutation. These two values combined, form the ciphertext., , The Avalanche Effect, A desirable property of any encryption algorithm is that a small change in either, the plaintext or the key should produce a significant change in the ciphertext. In, particular, a change in one bit of the plaintext or one bit of the key should produce
Page 135 :
134, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , 4.4 THE STRENGTH OF DES, Since its adoption as a federal standard, there have been lingering concerns about, the level of security provided by DES. These concerns, by and large, fall into two, areas: key size and the nature of the algorithm., , The Use of 56-Bit Keys, With a key length of 56 bits, there are 256 possible keys, which is approximately, 7.2 * 1016 keys. Thus, on the face of it, a brute-force attack appears impractical., Assuming that, on average, half the key space has to be searched, a single machine, performing one DES encryption per microsecond would take more than a thousand, years to break the cipher., However, the assumption of one encryption per microsecond is overly conservative. As far back as 1977, Diffie and Hellman postulated that the technology, existed to build a parallel machine with 1 million encryption devices, each of which, could perform one encryption per microsecond [DIFF77]. This would bring the, average search time down to about 10 hours. The authors estimated that the cost, would be about $20 million in 1977 dollars., With current technology, it is not even necessary to use special, purpose-built, hardware. Rather, the speed of commercial, off-the-shelf processors threaten the, security of DES. A recent paper from Seagate Technology [SEAG08] suggests that, a rate of 1 billion (109) key combinations per second is reasonable for today’s multicore computers. Recent offerings confirm this. Both Intel and AMD now offer, hardware-based instructions to accelerate the use of AES. Tests run on a contemporary multicore Intel machine resulted in an encryption rate of about half a billion encryptions per second [BASU12]. Another recent analysis suggests that with, contemporary supercomputer technology, a rate of 1013 encryptions per second is, reasonable [AROR12]., With these results in mind, Table 4.5 shows how much time is required for a, brute-force attack for various key sizes. As can be seen, a single PC can break DES in, about a year; if multiple PCs work in parallel, the time is drastically shortened. And, today’s supercomputers should be able to find a key in about an hour. Key sizes of, 128 bits or greater are effectively unbreakable using simply a brute-force approach., Even if we managed to speed up the attacking system by a factor of 1 trillion (1012),, it would still take over 100,000 years to break a code using a 128-bit key., Fortunately, there are a number of alternatives to DES, the most important of, which are AES and triple DES, discussed in Chapters 6 and 7, respectively., , The Nature of the DES Algorithm, Another concern is the possibility that cryptanalysis is possible by exploiting, the characteristics of the DES algorithm. The focus of concern has been on the, eight substitution tables, or S-boxes, that are used in each iteration (described in, Appendix S). Because the design criteria for these boxes, and indeed for the entire, algorithm, were not made public, there is a suspicion that the boxes were constructed in such a way that cryptanalysis is possible for an opponent who knows
Page 136 :
4.5 / BLOCK CIPHER DESIGN PRINCIPLES, , 135, , Table 4.5 Average Time Required for Exhaustive Key Search, Time Required at 109, Decryptions/s, , Time Required, at 1013, Decryptions/s, , Key Size (bits), , Cipher, , Number of, Alternative, Keys, , 56, , DES, , 256 ≈ 7.2 * 1016, , 255 ns = 1.125 years, , 1 hour, , 128, , AES, , 2128 ≈ 3.4 * 1038, , 2127 ns = 5.3 * 1021 years, , 5.3 * 1017 years, , 168, , Triple DES, , 2168 ≈ 3.7 * 1050, , 2167 ns = 5.8 * 1033 years, , 5.8 * 1029 years, , 192, , AES, , 2, , ns = 9.8 * 10 years, , 9.8 * 1036 years, , 256, , AES, , 2256 ≈ 1.2 * 1077, , 2255 ns = 1.8 * 1060 years, , 1.8 * 1056 years, , 26 characters, (permutation), , Monoalphabetic, , 2! = 4 * 1026, , 2 * 1026 ns = 6.3 * 109 years, , 6.3 * 106 years, , 192, , ≈ 6.3 * 10, , 57, , 191, , 2, , 40, , the weaknesses in the S-boxes. This assertion is tantalizing, and over the years a, number of regularities and unexpected behaviors of the S-boxes have been discovered. Despite this, no one has so far succeeded in discovering the supposed fatal, weaknesses in the S-boxes.9, , Timing Attacks, We discuss timing attacks in more detail in Part Two, as they relate to public-key, algorithms. However, the issue may also be relevant for symmetric ciphers. In, essence, a timing attack is one in which information about the key or the plaintext is, obtained by observing how long it takes a given implementation to perform decryptions on various ciphertexts. A timing attack exploits the fact that an encryption, or decryption algorithm often takes slightly different amounts of time on different, inputs. [HEVI99] reports on an approach that yields the Hamming weight (number, of bits equal to one) of the secret key. This is a long way from knowing the actual, key, but it is an intriguing first step. The authors conclude that DES appears to be, fairly resistant to a successful timing attack but suggest some avenues to explore., Although this is an interesting line of attack, it so far appears unlikely that this technique will ever be successful against DES or more powerful symmetric ciphers such, as triple DES and AES., , 4.5 BLOCK CIPHER DESIGN PRINCIPLES, Although much progress has been made in designing block ciphers that are cryptographically strong, the basic principles have not changed all that much since the, work of Feistel and the DES design team in the early 1970s. In this section we look, at three critical aspects of block cipher design: the number of rounds, design of the, function F, and key scheduling., , 9, , At least, no one has publicly acknowledged such a discovery.
Page 137 :
136, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , Number of Rounds, The cryptographic strength of a Feistel cipher derives from three aspects of the, design: the number of rounds, the function F, and the key schedule algorithm. Let, us look first at the choice of the number of rounds., The greater the number of rounds, the more difficult it is to perform cryptanalysis, even for a relatively weak F. In general, the criterion should be that the, number of rounds is chosen so that known cryptanalytic efforts require greater, effort than a simple brute-force key search attack. This criterion was certainly used, in the design of DES. Schneier [SCHN96] observes that for 16-round DES, a differential cryptanalysis attack is slightly less efficient than brute force: The differential cryptanalysis attack requires 255.1 operations,10 whereas brute force requires 255., If DES had 15 or fewer rounds, differential cryptanalysis would require less effort, than a brute-force key search., This criterion is attractive, because it makes it easy to judge the strength of, an algorithm and to compare different algorithms. In the absence of a cryptanalytic breakthrough, the strength of any algorithm that satisfies the criterion can be, judged solely on key length., , Design of Function F, The heart of a Feistel block cipher is the function F, which provides the element of, confusion in a Feistel cipher. Thus, it must be difficult to “unscramble” the substitution performed by F. One obvious criterion is that F be nonlinear, as we discussed, previously. The more nonlinear F, the more difficult any type of cryptanalysis will be., There are several measures of nonlinearity, which are beyond the scope of this, book. In rough terms, the more difficult it is to approximate F by a set of linear, equations, the more nonlinear F is., Several other criteria should be considered in designing F. We would like the, algorithm to have good avalanche properties. Recall that, in general, this means that, a change in one bit of the input should produce a change in many bits of the output., A more stringent version of this is the strict avalanche criterion (SAC) [WEBS86],, which states that any output bit j of an S-box (see Appendix S for a discussion of, S-boxes) should change with probability 1/2 when any single input bit i is inverted, for all i, j. Although SAC is expressed in terms of S-boxes, a similar criterion could, be applied to F as a whole. This is important when considering designs that do not, include S-boxes., Another criterion proposed in [WEBS86] is the bit independence criterion, (BIC), which states that output bits j and k should change independently when any, single input bit i is inverted for all i, j, and k. The SAC and BIC criteria appear to, strengthen the effectiveness of the confusion function., , 10, , Differential cryptanalysis of DES requires 247 chosen plaintext. If all you have to work with is known, plaintext, then you must sort through a large quantity of known plaintext–ciphertext pairs looking for the, useful ones. This brings the level of effort up to 255.1., , Hiva-Network.Com
Page 138 :
4.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 137, , Key Schedule Algorithm, With any Feistel block cipher, the key is used to generate one subkey for each round., In general, we would like to select subkeys to maximize the difficulty of deducing, individual subkeys and the difficulty of working back to the main key. No general, principles for this have yet been promulgated., Adams suggests [ADAM94] that, at minimum, the key schedule should guarantee key/ciphertext Strict Avalanche Criterion and Bit Independence Criterion., , 4.6 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, avalanche effect, block cipher, confusion, Data Encryption Standard, (DES), diffusion, , Feistel cipher, irreversible mapping, key, permutation, product cipher, reversible mapping, , round, round function, subkey, substitution, , Review Questions, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, , Briefly define a nonsingular transformation., What is the difference between a block cipher and a stream cipher?, Why is it not practical to use an arbitrary reversible substitution cipher of the kind, shown in Table 4.1?, Briefly define the terms substitution and permutation., What is the difference between diffusion and confusion?, Which parameters and design choices determine the actual algorithm of a Feistel, cipher?, What are the critical aspects of Feistel cipher design?, , Problems, 4.1, , a. In Section 4.1, under the subsection on the motivation for the Feistel cipher structure, it was stated that, for a block of n bits, the number of different reversible, mappings for the ideal block cipher is 2n!. Justify., b. In that same discussion, it was stated that for the ideal block cipher, which allows all, possible reversible mappings, the size of the key is n * 2n bits. But, if there are 2n!, possible mappings, it should take log 2 2n! bits to discriminate among the different, mappings, and so the key length should be log 2 2n!. However, log 2 2n! 6 n * 2n., Explain the discrepancy.
Page 139 :
138, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, 4.2, , Consider a Feistel cipher composed of sixteen rounds with a block length of 128 bits, and a key length of 128 bits. Suppose that, for a given k, the key scheduling algorithm, determines values for the first eight round keys, k1, k2, c k8, and then sets, k9 = k8, k10 = k7, k11 = k6, c , k16 = k1, , 4.3, , 4.4, , 4.5, , Suppose you have a ciphertext c. Explain how, with access to an encryption oracle,, you can decrypt c and determine m using just a single oracle query. This shows that, such a cipher is vulnerable to a chosen plaintext attack. (An encryption oracle can be, thought of as a device that, when given a plaintext, returns the corresponding ciphertext. The internal details of the device are not known to you and you cannot break, open the device. You can only gain information from the oracle by making queries to, it and observing its responses.), Let p be a permutation of the integers 0, 1, 2, c , (2n - 1), such that p(m) gives the, permuted value of m, 0 … m 6 2n. Put another way, p maps the set of n-bit integers, into itself and no two integers map into the same integer. DES is such a permutation, for 64-bit integers. We say that p has a fixed point at m if p(m) = m. That is, if p is, an encryption mapping, then a fixed point corresponds to a message that encrypts to, itself. We are interested in the number of fixed points in a randomly chosen permutation p. Show the somewhat unexpected result that the number of fixed points for p is, 1 on an average, and this number is independent of the size of the permutation., Consider a block encryption algorithm that encrypts blocks of length n, and let, N = 2n. Say we have t plaintext–ciphertext pairs Pi, Ci = E(K, Pi), where we assume, that the key K selects one of the N! possible mappings. Imagine that we wish to find K, by exhaustive search. We could generate key K′ and test whether Ci = E(K′, Pi) for, 1 … i … t. If K′ encrypts each Pi to its proper Ci, then we have evidence that K = K′., However, it may be the case that the mappings E(K, # ) and E(K′, # ) exactly agree, on the t plaintext–cipher text pairs Pi, Ci and agree on no other pairs., a. What is the probability that E(K, # ) and E(K′, # ) are in fact distinct mappings?, b. What is the probability that E(K, # ) and E(K′, # ) agree on another t′ plaintext–, ciphertext pairs where 0 … t′ … N - t?, For any block cipher, the fact that it is a nonlinear function is crucial to its security. To, see this, suppose that we have a linear block cipher EL that encrypts 256-bit blocks, of plaintext into 256-bit blocks of ciphertext. Let EL(k, m) denote the encryption of a, 256-bit message m under a key k (the actual bit length of k is irrelevant). Thus,, EL(k, [m1 ⊕ m2]) = EL(k, m1) ⊕ EL(k, m2) for all 128@bit patterns m1, m2., , 4.6, , Describe how, with 256 chosen ciphertexts, an adversary can decrypt any ciphertext, without knowledge of the secret key k. (A “chosen ciphertext” means that an adversary has the ability to choose a ciphertext and then obtain its decryption. Here, you, have 256 plaintext/ciphertext pairs to work with and you have the ability to choose, the value of the ciphertexts.), Suppose the DES F function mapped every 32-bit input R, regardless of the value of, the input K, to;, a. 32-bit string of zero, b. R, Then, 1. What function would DES then compute?, 2. What would the decryption look like?, Hint: Use the following properties of the XOR operation:, (A ⊕ B) ⊕ C = A ⊕ (B ⊕ C), (A ⊕ A) = 0, (A ⊕ 0 ) = A, A ⊕ 1 = bitwise complement of A
Page 140 :
4.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 4.7, 4.8, , 139, , where, A,B,C are n-bit strings of bits, 0 is an n-bit string of zeros, 1 is an n-bit string of one, Show that DES decryption is, in fact, the inverse of DES encryption., The 32-bit swap after the sixteenth iteration of the DES algorithm is needed to make, the encryption process invertible by simply running the ciphertext back through the, algorithm with the key order reversed. This was demonstrated in the preceding problem. However, it still may not be entirely clear why the 32-bit swap is needed. To, demonstrate why, solve the following exercises. First, some notation:, A‘B = the concatenation of the bit strings A and B, Ti(R ‘L) = the transformation defined by the ith iteration of the encryption, algorithm for 1 … I … 16, TDi(R ‘L) = the transformation defined by the ith iteration of the decryption, algorithm for 1 … I … 16, T17(R ‘L) = L ‘R, where this transformation occurs after the sixteenth iteration, of the encryption algorithm, a. Show that the composition TD1(IP(IP-1(T17(T16(L15 ‘R15))))) is equivalent to the, transformation that interchanges the 32-bit halves, L15 and R15. That is, show that, TD1(IP(IP-1(T17(T16(L15 ‘R15))))) = R15 ‘L15, b. Now suppose that we did away with the final 32-bit swap in the encryption algorithm. Then we would want the following equality to hold:, TD1(IP(IP-1(T16(L15 ‘R15)))) = L15 ‘R15, Does it?, , Note: The following problems refer to details of DES that are described in Appendix S., 4.9, 4.10, , 4.11, , Consider the substitution defined by row 1 of S-box S1 in Table S.2. Show a block, diagram similar to Figure 4.2 that corresponds to this substitution., Compute the bits number 4, 17, 41, and 45 at the output of the first round of the DES, decryption, assuming that the ciphertext block is composed of all ones and the external key is composed of all ones., This problem provides a numerical example of encryption using a one-round version, of DES. We start with the same bit pattern for the key K and the plaintext, namely:, Hexadecimal notation:, , 0123456789ABCDEF, , Binary notation:, , 0000 0001 0010 0011 0100 0101 0110 0111, 1000 1001 1010 1011 1100 1101 1110 1111, , Derive K1, the first-round subkey., Derive L0, R0., Expand R0 to get E[R0], where E[ # ] is the expansion function of Table S.1., Calculate A = E[R0] ⊕ K1., Group the 48-bit result of (d) into sets of 6 bits and evaluate the corresponding, S-box substitutions., f. Concatenate the results of (e) to get a 32-bit result, B., , a., b., c., d., e.
Page 141 :
140, , CHAPTER 4 / BLOCK CIPHERS AND THE DATA ENCRYPTION STANDARD, , 4.12, 4.13, , 4.14, , g. Apply the permutation to get P(B)., h. Calculate R1 = P(B) ⊕ L0., i. Write down the ciphertext., Analyze the amount of left shifts in the DES key schedule by studying Table S.3 (d)., Is there a pattern? What could be the reason for the choice of these constants?, When using the DES algorithm for decryption, the 16 keys (K1, K2, c , K16) are, used in reverse order. Therefore, the right-hand side of Figure S.1 is not valid for, decryption. Design a key-generation scheme with the appropriate shift schedule, (analogous to Table S.3d) for the decryption process., a. Let X′ be the bitwise complement of X. Prove that if the complement of the, plaintext block is taken and the complement of an encryption key is taken, then, the result of DES encryption with these values is the complement of the original, ciphertext. That is,, If, Then, , 4.15, , Y, Y′, , =, =, , E(K, X), E(K′, X′), , Hint: Begin by showing that for any two bit strings of equal length, A and B,, (A ⊕ B)′ = A′ ⊕ B., b. It has been said that a brute-force attack on DES requires searching a key space of, 256 keys. Does the result of part (a) change that?, a. We say that a DES key K is weak if DESK is an involution. Exhibit four weak, keys for DES., b. We say that a DES key K is semi-weak if it is not weak and if there exists a key K′, such that DESK- 1 = DESK′. Exhibit four semi-weak keys for DES., , Note: The following problems refer to simplified DES, described in Appendix G., 4.16 Refer to Figure G.3, which explains encryption function for S-DES., a. How important is the initial permutation IP?, b. How important is the SW function in the middle?, 4.17 The equations for the variables q and r for S-DES are defined in the section on, S-DES analysis. Provide the equations for s and t., 4.18 Using S-DES, decrypt the string 01000110 using the key 1010000010 by hand., Show intermediate results after each function (IP, FK, SW, FK, IP -1). Then decode, the first 4 bits of the plaintext string to a letter and the second 4 bits to another letter, where we encode A through P in base 2 (i.e., A = 0000, B = 0001, c , P = 1111)., Hint: As a midway check, after the xoring with K2, the string should be 11000001., , Programming Problems, 4.19, 4.20, , Create software that can encrypt and decrypt using a general substitution block, cipher., Create software that can encrypt and decrypt using S-DES. Test data: use plaintext,, ciphertext, and key of Problem 4.18.
Page 142 :
CHAPTER, , Finite Fields, 5.1, , Groups, Groups, Abelian Group, Cyclic Group, , 5.2, , Rings, , 5.3, , Fields, , 5.4, , Finite Fields of the Form GF(p), Finite Fields of Order p, Finding the Multiplicative Inverse in GF(p), Summary, , 5.5, , Polynomial Arithmetic, Ordinary Polynomial Arithmetic, Polynomial Arithmetic with Coefficients in Z p, Finding the Greatest Common Divisor, Summary, , 5.6, , Finite Fields of the form GF(2n), Motivation, Modular Polynomial Arithmetic, Finding the Multiplicative Inverse, Computational Considerations, Using a Generator, Summary, , 5.7, , Key Terms, Review Questions, and Problems, , 141
Page 143 :
142, , CHAPTER 5 / FINITE FIELDS, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Distinguish among groups, rings, and fields., ◆ Define finite fields of the form GF(p)., ◆ Explain the differences among ordinary polynomial arithmetic, polynomial, arithmetic with coefficients in Z p, and modular polynomial arithmetic in, GF(2n)., ◆ Define finite fields of the form GF(2n)., ◆ Explain the two different uses of the mod operator., , Finite fields have become increasingly important in cryptography. A number of, cryptographic algorithms rely heavily on properties of finite fields, notably the, Advanced Encryption Standard (AES) and elliptic curve cryptography. Other examples include the message authentication code CMAC and the authenticated encryption, scheme GCM., This chapter provides the reader with sufficient background on the concepts of, finite fields to be able to understand the design of AES and other cryptographic algorithms that use finite fields. Because students unfamiliar with abstract algebra may find, the concepts behind finite fields somewhat difficult to grasp, we approach the topic in a, way designed to enhance understanding. Our plan of attack is as follows:, 1. Fields are a subset of a larger class of algebraic structures called rings, which, are in turn a subset of the larger class of groups. In fact, as shown in Figure 5.1,, both groups and rings can be further differentiated. Groups are defined by, a simple set of properties and are easily understood. Each successive subset, (abelian group, ring, commutative ring, and so on) adds additional properties, and is thus more complex. Sections 5.1 through 5.3 will examine groups, rings,, and fields, successively., 2. Finite fields are a subset of fields, consisting of those fields with a finite number of elements. These are the class of fields that are found in cryptographic, algorithms. With the concepts of fields in hand, we turn in Section 5.4 to a, specific class of finite fields, namely those with p elements, where p is prime., Certain asymmetric cryptographic algorithms make use of such fields., 3. A more important class of finite fields, for cryptography, comprises those with, 2n elements depicted as fields of the form GF(2n). These are used in a wide, variety of cryptographic algorithms. However, before discussing these fields, we, need to analyze the topic of polynomial arithmetic, which is done in Section 5.5., 4. With all of this preliminary work done, we are able at last, in Section 5.6, to, discuss finite fields of the form GF(2n)., Before proceeding, the reader may wish to review Sections 2.1 through 2.3, which, cover relevant topics in number theory.
Page 144 :
5.1 / GROUPS, , 143, , Groups, Abelian groups, Rings, Commutative rings, Integral domains, Fields, Finite, fields, , Figure 5.1, , Groups, Rings, and Fields, , 5.1 GROUPS, Groups, rings, and fields are the fundamental elements of a branch of mathematics, known as abstract algebra, or modern algebra. In abstract algebra, we are concerned, with sets on whose elements we can operate algebraically; that is, we can combine, two elements of the set, perhaps in several ways, to obtain a third element of the set., These operations are subject to specific rules, which define the nature of the set. By, convention, the notation for the two principal classes of operations on set elements is, usually the same as the notation for addition and multiplication on ordinary numbers., However, it is important to note that, in abstract algebra, we are not limited to ordinary arithmetical operations. All this should become clear as we proceed., , Groups, A group G, sometimes denoted by {G, # }, is a set of elements with a binary operation denoted by # that associates to each ordered pair (a, b) of elements in G an, element (a # b) in G, such that the following axioms are obeyed:1, , 1, , (A1) Closure:, , If a and b belong to G, then a # b is also in G., , (A2) Associative:, , a # (b # c) = (a # b) # c for all a, b, c in G., , The operator # is generic and can refer to addition, multiplication, or some other mathematical operation.
Page 145 :
144, , CHAPTER 5 / FINITE FIELDS, (A3) Identity element:, , There is an element e in G such that, a # e = e # a = a for all a in G., , (A4) Inverse element:, , For each a in G, there is an element a′ in G, such that a # a′ = a′ # a = e., , Let Nn denote a set of n distinct symbols that, for convenience, we represent as, {1, 2, c , n}. A permutation of n distinct symbols is a one-to-one mapping from, Nn to Nn.2 Define Sn to be the set of all permutations of n distinct symbols. Each, element of Sn is represented by a permutation p of the integers in 1, 2, . . . , n., It is easy to demonstrate that Sn is a group:, A1: If (p, r ∈ Sn), then the composite mapping p # r is formed by permuting the elements of r according to the permutation p. For, example, {3, 2, 1} # {1, 3, 2} = {2, 3, 1}. The notation for this mapping is explained as follows: The value of the first element of p, indicates which element of r is to be in the first position in p # r; the, value of the second element of p indicates which element of r is, to be in the second position in p # r; and so on. Clearly, p # r ∈ Sn., A2: The composition of mappings is also easily seen to be associative., A3: The identity mapping is the permutation that does not alter the, order of the n elements. For Sn, the identity element is {1, 2, c , n}., A4: For any p ∈ Sn, the mapping that undoes the permutation defined, by p is the inverse element for p. There will always be such an, inverse. For example {2, 3, 1} # {3, 1, 2} = {1, 2, 3}., , If a group has a finite number of elements, it is referred to as a finite group, and, the order of the group is equal to the number of elements in the group. Otherwise,, the group is an infinite group., , Abelian Group, A group is said to be abelian if it satisfies the following additional condition:, (A5) Commutative:, , a # b = b # a for all a, b in G., , The set of integers (positive, negative, and 0) under addition is an abelian group., The set of nonzero real numbers under multiplication is an abelian group. The, set Sn from the preceding example is a group but not an abelian group for n 7 2., , 2, , This is equivalent to the definition of permutation in Chapter 2, which stated that a permutation of a, finite set of elements S is an ordered sequence of all the elements of S, with each element appearing, exactly once.
Page 146 :
5.2 / RINGS, , 145, , When the group operation is addition, the identity element is 0; the inverse element of a is -a; and subtraction is defined with the following rule:, a - b = a + ( -b)., , Cyclic Group, We define exponentiation within a group as a repeated application of the group, operator, so that a3 = a # a # a. Furthermore, we define a0 = e as the identity element, and a-n = (a′)n, where a′ is the inverse element of a within the group., A group G is cyclic if every element of G is a power ak (k is an integer) of a fixed, element a ∈ G. The element a is said to generate the group G or to be a generator, of G. A cyclic group is always abelian and may be finite or infinite., The additive group of integers is an infinite cyclic group generated by the element, 1. In this case, powers are interpreted additively, so that n is the nth power of 1., , 5.2 RINGS, A ring R, sometimes denoted by {R, +, * }, is a set of elements with two binary, operations, called addition and multiplication,3 such that for all a, b, c in R the following axioms are obeyed., (A1–A5) R is an abelian group with respect to addition; that is, R satisfies axioms, A1 through A5. For the case of an additive group, we denote the identity element, as 0 and the inverse of a as -a., (M1) Closure under multiplication:, , If a and b belong to R, then ab is also in R., , (M2) Associativity of multiplication:, , a(bc) = (ab)c for all a, b, c in R., , (M3) Distributive laws:, , a(b + c) = ab + ac for all a, b, c in R., (a + b)c = ac + bc for all a, b, c in R., , In essence, a ring is a set of elements in which we can do addition, subtraction, [a - b = a + ( -b)], and multiplication without leaving the set., With respect to addition and multiplication, the set of all n-square matrices over, the real numbers is a ring., A ring is said to be commutative if it satisfies the following additional condition:, (M4) Commutativity of multiplication:, , 3, , ab = ba for all a, b in R., , Generally, we do not use the multiplication symbol, * , but denote multiplication by the concatenation, of two elements., , Hiva-Network.Com
Page 147 :
146, , CHAPTER 5 / FINITE FIELDS, , Let S be the set of even integers (positive, negative, and 0) under the usual, operations of addition and multiplication. S is a commutative ring. The set of all, n-square matrices defined in the preceding example is not a commutative ring., The set Z n of integers {0, 1, c , n - 1}, together with the arithmetic operations modulo n, is a commutative ring (Table 4.3)., Next, we define an integral domain, which is a commutative ring that obeys, the following axioms., (M5) Multiplicative identity:, , There is an element 1 in R such that, a1 = 1a = a for all a in R., , (M6) No zero divisors:, , If a, b in R and ab = 0, then either a = 0, or b = 0., , Let S be the set of integers (positive, negative, and 0) under the usual operations, of addition and multiplication. S is an integral domain., , 5.3 FIELDS, A field F, sometimes denoted by {F, +, * }, is a set of elements with two binary, operations, called addition and multiplication, such that for all a, b, c in F the following axioms are obeyed., (A1–M6) F is an integral domain; that is, F satisfies axioms A1 through A5 and, M1 through M6., (M7) Multiplicative inverse:, , For each a in F, except 0, there is an element, a-1 in F such that aa-1 = (a-1)a = 1., , In essence, a field is a set of elements in which we can do addition, subtraction,, multiplication, and division without leaving the set. Division is defined with the following rule: a/b = a(b-1)., Familiar examples of fields are the rational numbers, the real numbers, and the, complex numbers. Note that the set of all integers is not a field, because not every, element of the set has a multiplicative inverse; in fact, only the elements 1 and -1, have multiplicative inverses in the integers., In gaining insight into fields, the following alternate characterization may be, useful. A field F, denoted by {F, +}, is a set of elements with two binary operations,, called addition and multiplication, such that the following conditions hold:, 1. F forms an abelian group with respect to addition., 2. The nonzero elements of F form an abelian group with respect to multiplication.
Page 148 :
5.4 / FINITE FIELDS OF THE FORM GF( p), , 147, , 3. The distributive law holds. That is, for all a, b, c in F,, a(b + c) = ab + ac., (a + b)c = ac + bc, 4. Figure 5.2 summarizes the axioms that define groups, rings, and fields., , 5.4 FINITE FIELDS OF THE FORM GF(p), In Section 5.3, we defined a field as a set that obeys all of the axioms of Figure 5.2, and gave some examples of infinite fields. Infinite fields are not of particular interest in the context of cryptography. However, in addition to infinite fields, there are, two types of finite fields, as illustrated in Figure 5.3. Finite fields play a crucial role, in many cryptographic algorithms., It can be shown that the order of a finite field (number of elements in the, field) must be a power of a prime pn, where n is a positive integer. The finite field, of order pn is generally written GF(pn); GF stands for Galois field, in honor of the, mathematician who first studied finite fields. Two special cases are of interest for, our purposes. For n = 1, we have the finite field GF(p); this finite field has a different structure than that for finite fields with n 7 1 and is studied in this section. For, finite fields of the form GF(pn), GF(2n) fields are of particular cryptographic interest, and these are covered in Section 5.6., , Finite Fields of Order p, , Group, , Abelian group, , Ring, , Commutative ring, , Integral domain, , Field, , For a given prime, p, we define the finite field of order p, GF(p), as the set Z p of integers, {0, 1, c , p - 1} together with the arithmetic operations modulo p. Note therefore, that we are using ordinary modular arithmetic to define the operations over these fields., (A1) Closure under addition:, (A2) Associativity of addition:, (A3) Additive identity:, (A4) Additive inverse:, (A5) Commutativity of addition:, , If a and b belong to S, then a + b is also in S, a + (b + c) = (a + b) + c for all a, b, c in S, There is an element 0 in R such that, a + 0 = 0 + a = a for all a in S, For each a in S there is an element –a in S, such that a + (–a) = (–a) + a = 0, a + b = b + a for all a, b in S, , (M1) Closure under multiplication: If a and b belong to S, then ab is also in S, (M2) Associativity of multiplication: a(bc) = (ab)c for all a, b, c in S, (M3) Distributive laws:, a(b + c) = ab + ac for all a, b, c in S, (a + b)c = ac + bc for all a, b, c in S, (M4) Commutativity of multiplication:, (M5) Multiplicative identity:, (M6) No zero divisors:, (M7) Multiplicative inverse:, , Figure 5.2, , Properties of Groups, Rings, and Fields, , ab = ba for all a, b in S, , There is an element 1 in S such that, a1 = 1a = a for all a in S, If a, b in S and ab = 0, then either, a = 0 or b = 0, If a belongs to S and a ≠ 0, there is an, element a –1 in S such that aa –1 = a –1a = 1
Page 149 :
148, , CHAPTER 5 / FINITE FIELDS, Fields, , Fields with an, infinite number, of elements, , Finite fields, , GF(pn), Finite fields, with pn elements, , GF(p), Finite fields, with p elements, , Figure 5.3 Types of Fields, , Recall that we showed in Section 5.2 that the set Z n of integers {0, 1, c , n - 1},, together with the arithmetic operations modulo n, is a commutative ring (Table 2.5)., We further observed that any integer in Z n has a multiplicative inverse if and only if, that integer is relatively prime to n [see discussion of Equation (2.5)].4 If n is prime,, then all of the nonzero integers in Z n are relatively prime to n, and therefore there, exists a multiplicative inverse for all of the nonzero integers in Z n. Thus, for Z p we, can add the following properties to those listed in Table 5.2:, Multiplicative, inverse (w -1), , For each w ∈ Z p, w ≠ 0, there exists a z ∈ Z p, such that w * z K 1 (mod p), , Because w is relatively prime to p, if we multiply all the elements of Z p by, w, the resulting residues are all of the elements of Z p permuted. Thus, exactly one, of the residues has the value 1. Therefore, there is some integer in Z p that, when, multiplied by w, yields the residue 1. That integer is the multiplicative inverse of w,, designated w -1. Therefore, Z p is in fact a finite field. Furthermore, Equation (2.5) is, consistent with the existence of a multiplicative inverse and can be rewritten without the condition:, if (a * b) K (a * c)(mod p) then b K c(mod p), , (5.1), , Multiplying both sides of Equation (5.1) by the multiplicative inverse of a, we have, ((a-1) * a * b) K ((a -1) * a * c)(mod p), b K c (mod p), The simplest finite field is GF(2). Its arithmetic operations are easily summarized:, +, , 0, , 1, , *, , 0, , 1, , w, , -w, , w -1, , 0, , 0, , 1, , 0, , 0, , 0, , 0, , 0, , -, , 1, , 1, , 0, , 1, , 0, , 1, , 1, , 1, , 1, , Addition, , Multiplication, , Inverses, , In this case, addition is equivalent to the exclusive-OR (XOR) operation, and, multiplication is equivalent to the logical AND operation., 4, , As stated in the discussion of Equation (2.5), two integers are relatively prime if their only common, positive integer factor is 1.
Page 150 :
5.4 / FINITE FIELDS OF THE FORM GF( p), , 149, , The right-hand side of Table 5.1 shows arithmetic operations in GF(7). This is a, field of order 7 using modular arithmetic modulo 7. As can be seen, it satisfies all, of the properties required of a field (Figure 5.2). Compare with the left-hand side, of Table 5.1, which reproduces Table 2.2. In the latter case, we see that the set Z 8,, using modular arithmetic modulo 8, is not a field. Later in this chapter, we show, how to define addition and multiplication operations on Z 8 in such a way as to, form a finite field., , Finding the Multiplicative Inverse in GF(p), It is easy to find the multiplicative inverse of an element in GF(p) for small values, of p. You simply construct a multiplication table, such as shown in Table 5.1e, and, the desired result can be read directly. However, for large values of p, this approach, is not practical., If a and b are relatively prime, then b has a multiplicative inverse modulo a., That is, if gcd(a, b) = 1, then b has a multiplicative inverse modulo a. That is, for, positive integer b 6 a, there exists a b-1 6 a such that bb-1 = 1 mod a. If a is a, prime number and b 6 a, then clearly a and b are relatively prime and have a greatest common divisor of 1. We now show that we can easily compute b-1 using the, extended Euclidean algorithm., We repeat here Equation (2.7), which we showed can be solved with the extended Euclidean algorithm:, ax + by = d = gcd(a, b), Now, if gcd(a, b) = 1, then we have ax + by = 1. Using the basic equalities of, modular arithmetic, defined in Section 2.3, we can say, [(ax mod a) + (by mod a)] mod a = 1 mod a, 0 + (by mod a) = 1, But if by mod a = 1, then y = b-1. Thus, applying the extended Euclidean, algorithm to Equation (2.7) yields the value of the multiplicative inverse of b if, gcd(a, b) = 1., , Consider the example that was shown in Table 2.4. Here we have a = 1759,, which is a prime number, and b = 550. The solution of the equation, 1759x + 550y = d yields a value of y = 355. Thus, b-1 = 355. To verify, we calculate 550 * 355 mod 1759 = 195250 mod 1759 = 1., , More generally, the extended Euclidean algorithm can be used to find a, multiplicative inverse in Z n for any n. If we apply the extended Euclidean algorithm, to the equation nx + by = d, and the algorithm yields d = 1, then y = b-1 in Z n.
Page 151 :
150, , CHAPTER 5 / FINITE FIELDS, Table 5.1 Arithmetic Modulo 8 and Modulo 7, +, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , +, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 1, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 0, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 2, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 1, , 1, , 1, , 2, , 3, , 4, , 5, , 6, , 0, , 3, , 3, , 4, , 5, , 6, , 7, , 0, , 1, , 2, , 2, , 2, , 3, , 4, , 5, , 6, , 0, , 1, , 4, , 4, , 5, , 6, , 7, , 0, , 1, , 2, , 3, , 3, , 3, , 4, , 5, , 6, , 0, , 1, , 2, , 5, , 5, , 6, , 7, , 0, , 1, , 2, , 3, , 4, , 4, , 4, , 5, , 6, , 0, , 1, , 2, , 3, , 6, , 6, , 7, , 0, , 1, , 2, , 3, , 4, , 5, , 5, , 5, , 6, , 0, , 1, , 2, , 3, , 4, , 7, , 7, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 6, , 6, , 0, , 1, , 2, , 3, , 4, , 5, , (a) Addition modulo 8, , (d) Addition modulo 7, , *, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , *, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 1, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 2, , 0, , 2, , 4, , 6, , 0, , 2, , 4, , 6, , 1, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 0, , 2, , 4, , 6, , 1, , 3, , 5, , 3, , 0, , 3, , 6, , 1, , 4, , 7, , 2, , 5, , 2, , 4, , 0, , 4, , 0, , 4, , 0, , 4, , 0, , 4, , 3, , 0, , 3, , 6, , 2, , 5, , 1, , 4, , 5, , 0, , 5, , 2, , 7, , 4, , 1, , 6, , 3, , 4, , 0, , 4, , 1, , 5, , 2, , 6, , 3, , 0, , 5, , 3, , 1, , 6, , 4, , 2, , 0, , 6, , 5, , 4, , 3, , 2, , 1, , 6, , 0, , 6, , 4, , 2, , 0, , 6, , 4, , 2, , 5, , 7, , 0, , 7, , 6, , 5, , 4, , 3, , 2, , 1, , 6, , (b) Multiplication modulo 8, , (e) Multiplication modulo 7, , w, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , w, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , -w, , 0, , 7, , 6, , 5, , 4, , 3, , 2, , 1, , -w 0, , 6, , 5, , 4, , 3, , 2, , 1, , w, , —, , 1, , —, , 3, , —, , 5, , —, , 7, , w, , 1, , 4, , 5, , 2, , 3, , 6, , -1, , (c) Additive and multiplicative, inverses modulo 8, , -1, , —, , (f) Additive and multiplicative, inverses modulo 7, , Summary, In this section, we have shown how to construct a finite field of order p, where p is, prime. Specifically, we defined GF(p) with the following properties., 1. GF(p) consists of p elements., 2. The binary operations + and * are defined over the set. The operations of, addition, subtraction, multiplication, and division can be performed without, leaving the set. Each element of the set other than 0 has a multiplicative inverse, and division is performed by multiplication by the multiplicative inverse., We have shown that the elements of GF(p) are the integers {0, 1, c , p - 1}, and that the arithmetic operations are addition and multiplication mod p.
Page 152 :
5.5 / POLYNOMIAL ARITHMETIC, , 151, , 5.5 POLYNOMIAL ARITHMETIC, Before continuing our discussion of finite fields, we need to introduce the interesting subject of polynomial arithmetic. We are concerned with polynomials in a single, variable x, and we can distinguish three classes of polynomial arithmetic (Figure 5.4)., ■, ■, ■, , Ordinary polynomial arithmetic, using the basic rules of algebra., Polynomial arithmetic in which the arithmetic on the coefficients is performed, modulo p; that is, the coefficients are in GF(p)., Polynomial arithmetic in which the coefficients are in GF(p), and the polynomials are defined modulo a polynomial m(x) whose highest power is some, integer n., , This section examines the first two classes, and the next section covers the, last class., , Ordinary Polynomial Arithmetic, A polynomial of degree n (integer n Ú 0) is an expression of the form, n, , f(x) = anxn + an - 1xn - 1 + g + a1x + a0 = a aixi, i=0, , where the ai are elements of some designated set of numbers S, called the coefficient, set, and an ≠ 0. We say that such polynomials are defined over the coefficient set S., A zero-degree polynomial is called a constant polynomial and is simply an, element of the set of coefficients. An nth-degree polynomial is said to be a monic, polynomial if an = 1., In the context of abstract algebra, we are usually not interested in evaluating a, polynomial for a particular value of x [e.g., f(7)]. To emphasize this point, the variable x is sometimes referred to as the indeterminate., Polynomial arithmetic includes the operations of addition, subtraction, and, multiplication. These operations are defined in a natural way as though the variable, Polynomial f(x), , x treated as a variable,, and evaluated for, a particular value of x, , Ordinary, polynomial, arithmetic, , x treated as an, indeterminate, , Arithmetic on, coefficients is, performed, modulo p, , Figure 5.4 Treatment of Polynomials, , Arithmetic on coefficients is, performed modulo p, and polynomials are defined, modulo a polynomial m(x)
Page 153 :
152, , CHAPTER 5 / FINITE FIELDS, , x was an element of S. Division is similarly defined, but requires that S be a field., Examples of fields include the real numbers, rational numbers, and Z p for p prime., Note that the set of all integers is not a field and does not support polynomial, division., Addition and subtraction are performed by adding or subtracting corresponding coefficients. Thus, if, n, , m, , i=0, , i=0, , f(x) = a aixi; g(x) = a bixi; n Ú m, then addition is defined as, m, , f(x) + g(x) = a (ai + bi)xi +, i=0, , n, i, a aix, , i=m+1, , and multiplication is defined as, n+m, , f(x) * g(x) = a cixi, i=0, , where, ck = a0bk + a1bk - 1 + g + ak - 1b1 + akb0, In the last formula, we treat ai as zero for i 7 n and bi as zero for i 7 m. Note that, the degree of the product is equal to the sum of the degrees of the two polynomials., As an example, let f(x) = x3 + x2 + 2 and g(x) = x2 - x + 1, where S is the set, of integers. Then, f(x) + g(x) = x3 + 2x2 - x + 3, f(x) - g(x) = x3 + x + 1, f(x) * g(x) = x5 + 3x2 - 2x + 2, Figures 5.5a through 5.5c show the manual calculations. We comment on division, subsequently., , Polynomial Arithmetic with Coefficients in Zp, Let us now consider polynomials in which the coefficients are elements of some, field F; we refer to this as a polynomial over the field F. In this case, it is easy to, show that the set of such polynomials is a ring, referred to as a polynomial ring. That, is, if we consider each distinct polynomial to be an element of the set, then that set, is a ring.5, When polynomial arithmetic is performed on polynomials over a field, then, division is possible. Note that this does not mean that exact division is possible. Let, 5, , In fact, the set of polynomials whose coefficients are elements of a commutative ring forms a polynomial, ring, but that is of no interest in the present context.
Page 154 :
5.5 / POLYNOMIAL ARITHMETIC, x3 + x2, , x3 + x2, , +2, , +, , ( x2, , x3, , +2x2 –, , – x +1), , –, , x + 3, , × (, , x2, , – x4 – x3, , – x + 1), , x +2, x2, , – x +1, , + 2, – 2x, , x5 + x4, , +2x2, , x5, , +3x2 –, , x3 + x2, , +2, , x3 – x2 + x, 2x2 – x + 2, 2x2 – 2x + 2, x, , 2x + 2, , (c) Multiplication, , Figure 5.5, , – x + 1), +x + 1, , +2, , x3 + x2, , +2, , (b) Subtraction, , (a) Addition, , x3 + x2, , (, , x3, , x2, , 153, , (d) Division, , Examples of Polynomial Arithmetic, , us clarify this distinction. Within a field, given two elements a and b, the quotient, a/b is also an element of the field. However, given a ring R that is not a field, in general, division will result in both a quotient and a remainder; this is not exact division., Consider the division 5/3 within a set S. If S is the set of rational numbers, which, is a field, then the result is simply expressed as 5/3 and is an element of S. Now, suppose that S is the field Z 7. In this case, we calculate (using Table 5.1f), 5/3 = (5 * 3-1) mod 7 = (5 * 5) mod 7 = 4, which is an exact solution. Finally, suppose that S is the set of integers, which is a, ring but not a field. Then 5/3 produces a quotient of 1 and a remainder of 2:, 5/3 = 1 + 2/3, 5 = 1 * 3 + 2, Thus, division is not exact over the set of integers., Now, if we attempt to perform polynomial division over a coefficient set that, is not a field, we find that division is not always defined., If the coefficient set is the integers, then (5x2)/(3x) does not have a solution,, because it would require a coefficient with a value of 5/3, which is not in the coefficient set. Suppose that we perform the same polynomial division over Z 7. Then, we have (5x2)/(3x) = 4x, which is a valid polynomial over Z 7., However, as we demonstrate presently, even if the coefficient set is a field,, polynomial division is not necessarily exact. In general, division will produce a quotient and a remainder. We can restate the division algorithm of Equation (2.1) for, polynomials over a field as follows. Given polynomials f(x) of degree n and g(x)
Page 155 :
154, , CHAPTER 5 / FINITE FIELDS, , of degree (m), (n Ú m), if we divide f(x) by g(x), we get a quotient q(x) and a, remainder r(x) that obey the relationship, f(x) = q(x)g(x) + r(x), , (5.2), , with polynomial degrees:, Degree f(x) = n, Degree g(x) = m, Degree q(x) = n - m, Degree r(x) … m - 1, With the understanding that remainders are allowed, we can say that polynomial division is possible if the coefficient set is a field. One common technique, used for polynomial division is polynomial long division, similar to long division for, integers. Examples of this are shown subsequently., In an analogy to integer arithmetic, we can write f(x) mod g(x) for the remainder r(x) in Equation (5.2). That is, r(x) = f(x) mod g(x). If there is no remainder, [i.e., r(x) = 0], then we can say g(x) divides f(x), written as g(x) f(x). Equivalently,, we can say that g(x) is a factor of f(x) or g(x) is a divisor of f(x)., For the preceding example [f(x) = x3 + x2 + 2 and g(x) = x2 - x + 1], f(x)/g(x), produces a quotient of q(x) = x + 2 and a remainder r(x) = x, as shown in, Figure 5.5d. This is easily verified by noting that, q(x)g(x) + r(x) = (x + 2)(x2 - x + 1) + x = (x3 + x2 - x + 2) + x, = x3 + x2 + 2 = f(x), For our purposes, polynomials over GF(2) are of most interest. Recall from, Section 5.4 that in GF(2), addition is equivalent to the XOR operation, and multiplication is equivalent to the logical AND operation. Further, addition and subtraction are equivalent mod 2:, 1 + 1 = 1 - 1 = 0, 1 + 0 = 1 - 0 = 1, 0 + 1 = 0 - 1 = 1, Figure 5.6 shows an example of polynomial arithmetic over GF(2). For, f(x) = (x7 + x5 + x4 + x3 + x + 1) and g(x) = (x3 + x + 1), the figure shows, f(x) + g(x); f(x) - g(x); f(x) * g(x); and f(x)/g(x). Note that g(x) f(x)., A polynomial f(x) over a field F is called irreducible if and only if f(x) cannot be expressed as a product of two polynomials, both over F, and both of degree, lower than that of f(x). By analogy to integers, an irreducible polynomial is also, called a prime polynomial., The polynomial6 f(x) = x4 + 1 over GF(2) is reducible, because, x4 + 1 = (x + 1)(x3 + x2 + x + 1)., 6, , In the reminder of this chapter, unless otherwise noted, all examples are of polynomials over GF(2)., , Hiva-Network.Com
Page 157 :
156, , CHAPTER 5 / FINITE FIELDS, , Finding the Greatest Common Divisor, We can extend the analogy between polynomial arithmetic over a field and integer, arithmetic by defining the greatest common divisor as follows. The polynomial c(x), is said to be the greatest common divisor of a(x) and b(x) if the following are true., 1. c(x) divides both a(x) and b(x)., 2. Any divisor of a(x) and b(x) is a divisor of c(x)., An equivalent definition is the following: gcd[a(x), b(x)] is the polynomial of, maximum degree that divides both a(x) and b(x)., We can adapt the Euclidean algorithm to compute the greatest common divisor, of two polynomials. Recall Equation (2.6), from Chapter 2, which is the basis of the, Euclidean algorithm: gcd(a, b) = gcd(b, a mod b). This equality can be rewritten as the, following equation:, gcd[a(x), b(x)] = gcd[b(x), a(x) mod b(x)], , (5.3), , Equation (5.3) can be used repetitively to determine the greatest common divisor., Compare the following scheme to the definition of the Euclidean algorithm for integers., Euclidean Algorithm for Polynomials, Calculate, , Which satisfies, , r1(x) = a(x) mod b(x), , a(x) = q1(x)b(x) + r1(x), , r2(x) = b(x) mod r1(x), , b(x) = q2(x)r1(x) + r2(x), , r3(x) = r1(x) mod r2(x), r, r, r, , r1(x) = q3(x)r2(x) + r3(x), r, r, r, , rn(x) = rn - 2(x) mod rn - 1(x), , rn - 2(x) = qn(x)rn - 1(x) + rn(x), , rn + 1(x) = rn - 1(x) mod rn(x) = 0, , rn - 1(x) = qn + 1(x)rn(x) + 0, d(x) = gcd(a(x), b(x)) = rn(x), , At each iteration, we have d(x) = gcd(ri + 1(x), ri(x)) until finally, d(x) = gcd(rn(x), 0) = rn(x). Thus, we can find the greatest common divisor of two, integers by repetitive application of the division algorithm. This is the Euclidean, algorithm for polynomials. The algorithm assumes that the degree of a(x) is greater, than the degree of b(x)., Find gcd[a(x), b(x)] for a(x) = x6 + x5 + x4 + x3 + x2 + x + 1 and b(x) =, x4 + x2 + x + 1. First, we divide a(x) by b(x):, x2 + x, x4 + x2 + x + 1 x6 + x5 + x4 + x3 + x2 + x + 1, x6, + x4 + x3 + x2, x5, + x + 1, x5, + x3 + x2 + x, x3 + x2, + 1
Page 158 :
5.6 / FINITE FIELDS OF THE FORM GF(2n), , 157, , This yields r1(x) = x3 + x2 + 1 and q1 (x) = x2 + x., Then, we divide b(x) by r1(x)., x + 1, 3, , 2, , 4, , x + x + 1x, + x2 + x + 1, 4, 3, x + x, + x, 3, 2, x + x, + 1, x3 + x2, + 1, This yields r2(x) = 0 and q2(x) = x + 1., Therefore, gcd[a(x), b(x)] = r1(x) = x3 + x2 + 1., , Summary, We began this section with a discussion of arithmetic with ordinary polynomials. In, ordinary polynomial arithmetic, the variable is not evaluated; that is, we do not plug, a value in for the variable of the polynomials. Instead, arithmetic operations are, performed on polynomials (addition, subtraction, multiplication, division) using the, ordinary rules of algebra. Polynomial division is not allowed unless the coefficients, are elements of a field., Next, we discussed polynomial arithmetic in which the coefficients are elements of GF(p). In this case, polynomial addition, subtraction, multiplication, and, division are allowed. However, division is not exact; that is, in general division results in a quotient and a remainder., Finally, we showed that the Euclidean algorithm can be extended to find the, greatest common divisor of two polynomials whose coefficients are elements of a, field., All of the material in this section provides a foundation for the following section, in which polynomials are used to define finite fields of order pn., , 5.6 FINITE FIELDS OF THE FORM GF(2n), Earlier in this chapter, we mentioned that the order of a finite field must be of the, form pn, where p is a prime and n is a positive integer. In Section 5.4, we looked at, the special case of finite fields with order p. We found that, using modular arithmetic in Z p, all of the axioms for a field (Figure 5.2) are satisfied. For polynomials, over pn, with n 7 1, operations modulo pn do not produce a field. In this section,, we show what structure satisfies the axioms for a field in a set with pn elements and, concentrate on GF(2n)., , Motivation, Virtually all encryption algorithms, both symmetric and asymmetric, involve arithmetic operations on integers. If one of the operations that is used in the algorithm is, division, then we need to work in arithmetic defined over a field. For convenience
Page 159 :
158, , CHAPTER 5 / FINITE FIELDS, , and for implementation efficiency, we would also like to work with integers that fit, exactly into a given number of bits with no wasted bit patterns. That is, we wish to, work with integers in the range 0 through 2n - 1, which fit into an n-bit word., Suppose we wish to define a conventional encryption algorithm that operates on, data 8 bits at a time, and we wish to perform division. With 8 bits, we can represent integers in the range 0 through 255. However, 256 is not a prime number, so, that if arithmetic is performed in Z 256 (arithmetic modulo 256), this set of integers will not be a field. The closest prime number less than 256 is 251. Thus, the, set Z 251, using arithmetic modulo 251, is a field. However, in this case the 8-bit, patterns representing the integers 251 through 255 would not be used, resulting, in inefficient use of storage., As the preceding example points out, if all arithmetic operations are to be, used and we wish to represent a full range of integers in n bits, then arithmetic, modulo 2n will not work. Equivalently, the set of integers modulo 2n for n 7 1, is, not a field. Furthermore, even if the encryption algorithm uses only addition and, multiplication, but not division, the use of the set Z 2n is questionable, as the following example illustrates., Suppose we wish to use 3-bit blocks in our encryption algorithm and use only the, operations of addition and multiplication. Then arithmetic modulo 8 is well defined,, as shown in Table 5.1. However, note that in the multiplication table, the nonzero, integers do not appear an equal number of times. For example, there are only four, occurrences of 3, but twelve occurrences of 4. On the other hand, as was mentioned,, there are finite fields of the form GF(2n), so there is in particular a finite field of, order 23 = 8. Arithmetic for this field is shown in Table 5.2. In this case, the number, of occurrences of the nonzero integers is uniform for multiplication. To summarize,, Integer, Occurrences in Z 8, Occurrences in GF(23), , 1, 4, 7, , 2, 8, 7, , 3, 4, 7, , 4, 12, 7, , 5, 4, 7, , 6, 8, 7, , 7, 4, 7, , For the moment, let us set aside the question of how the matrices of Table 5.2, were constructed and instead make some observations., 1. The addition and multiplication tables are symmetric about the main diagonal, in conformance to the commutative property of addition and multiplication. This property is also exhibited in Table 5.1, which uses mod 8 arithmetic., 2. All the nonzero elements defined by Table 5.2 have a multiplicative inverse,, unlike the case with Table 5.1., 3. The scheme defined by Table 5.2 satisfies all the requirements for a finite, field. Thus, we can refer to this scheme as GF(23)., 4. For convenience, we show the 3-bit assignment used for each of the elements, of GF(23).
Page 160 :
5.6 / FINITE FIELDS OF THE FORM GF(2n), , 159, , Intuitively, it would seem that an algorithm that maps the integers unevenly, onto themselves might be cryptographically weaker than one that provides a uniform mapping. That is, a cryptanalytic technique might be able to exploit the fact, that some integers occur more frequently and some less frequently in the ciphertext., Thus, the finite fields of the form GF(2n) are attractive for cryptographic algorithms., To summarize, we are looking for a set consisting of 2n elements, together, with a definition of addition and multiplication over the set that define a field. We, can assign a unique integer in the range 0 through 2n - 1 to each element of the, set. Keep in mind that we will not use modular arithmetic, as we have seen that this, does not result in a field. Instead, we will show how polynomial arithmetic provides, a means for constructing the desired field., , Modular Polynomial Arithmetic, Consider the set S of all polynomials of degree n - 1 or less over the field Z p. Thus,, each polynomial has the form, n-1, , f(x) = an - 1xn - 1 + an - 2xn - 2 + g + a1x + a0 = a aixi, i=0, , Table 5.2 Arithmetic in GF(23), 000, , 001, , 010, , 011, , 100, , 101, , 110, , 111, , +, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 000, , 0, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 001, , 1, , 1, , 0, , 3, , 2, , 5, , 4, , 7, , 6, , 010, , 2, , 2, , 3, , 0, , 1, , 6, , 7, , 4, , 5, , 011, , 3, , 3, , 2, , 1, , 0, , 7, , 6, , 5, , 4, , 100, , 4, , 4, , 5, , 6, , 7, , 0, , 1, , 2, , 3, , 101, , 5, , 5, , 4, , 7, , 6, , 1, , 0, , 3, , 2, , 110, , 6, , 6, , 7, , 4, , 5, , 2, , 3, , 0, , 1, , 111, , 7, , 7, , 6, , 5, , 4, , 3, , 2, , 1, , 0, , (a) Addition, 000, , 001, , 010, , 011, , 100, , 101, , 110, , 111, , w, , -w, , w -1, , *, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 0, , 0, , -, , 000, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 0, , 1, , 1, , 1, , 001, , 1, , 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 2, , 2, , 5, , 010, , 2, , 0, , 2, , 4, , 6, , 3, , 1, , 7, , 5, , 3, , 3, , 6, , 011, , 3, , 0, , 3, , 6, , 5, , 7, , 4, , 1, , 2, , 4, , 4, , 7, , 100, , 4, , 0, , 4, , 3, , 7, , 6, , 2, , 5, , 1, , 5, , 5, , 2, , 101, , 5, , 0, , 5, , 1, , 4, , 2, , 7, , 3, , 6, , 6, , 6, , 3, , 110, , 6, , 0, , 6, , 7, , 1, , 5, , 3, , 2, , 4, , 7, , 7, , 4, , 111, , 7, , 0, , 7, , 5, , 2, , 1, , 6, , 4, , 3, , (b) Multiplication, , (c) Additive and multiplicative, inverses
Page 162 :
5.6 / FINITE FIELDS OF THE FORM GF(2n), , 161, , As with ordinary modular arithmetic, we have the notion of a set of residues, in modular polynomial arithmetic. The set of residues modulo m(x), an nth-degree, polynomial, consists of pn elements. Each of these elements is represented by one of, the pn polynomials of degree m 6 n., , The residue class [x + 1], (mod m(x)), consists of all polynomials a(x) such that, a(x) K (x + 1)(mod m(x)). Equivalently, the residue class [x + 1] consists of all, polynomials a(x) that satisfy the equality a(x) mod m(x) = x + 1., , It can be shown that the set of all polynomials modulo an irreducible nthdegree polynomial m(x) satisfies the axioms in Figure 5.2, and thus forms a finite, field. Furthermore, all finite fields of a given order are isomorphic; that is, any two, finite-field structures of a given order have the same structure, but the representation or labels of the elements may be different., , To construct the finite field GF(23), we need to choose an irreducible polynomial of degree 3. There are only two such polynomials: (x3 + x2 + 1) and, (x3 + x + 1). Using the latter, Table 5.3 shows the addition and multiplication, tables for GF(23). Note that this set of tables has the identical structure to those, of Table 5.2. Thus, we have succeeded in finding a way to define a field of order 23., We can now read additions and multiplications from the table easily. For example, consider binary 100 + 010 = 110. This is equivalent to x2 + x. Also consider, 100 * 010 = 011, which is equivalent to x2 * x = x3 and reduces to x + 1. That, is, x3 mod (x3 + x + 1) = x + 1, which is equivalent to 011., , Finding the Multiplicative Inverse, Just as the Euclidean algorithm can be adapted to find the greatest common divisor, of two polynomials, the extended Euclidean algorithm can be adapted to find the, multiplicative inverse of a polynomial. Specifically, the algorithm will find the multiplicative inverse of b(x) modulo a(x) if the degree of b(x) is less than the degree of, a(x) and gcd[a(x), b(x)] = 1. If a(x) is an irreducible polynomial, then it has no factor other than itself or 1, so that gcd[a(x), b(x)] = 1. The algorithm can be characterized in the same way as we did for the extended Euclidean algorithm for integers., Given polynomials a(x) and b(x) with the degree of a(x) greater than the degree, of b(x), we wish to solve the following equation for the values v(x), w(x), and d(x),, where d(x) = gcd[a(x), b(x)]:, a(x)v(x) + b(x)w(x) = d(x), If d(x) = 1, then w(x) is the multiplicative inverse of b(x) modulo a(x). The calculations are as follows.
Page 163 :
1, , x2, x2 + 1, x2 + x, , x2 + x + 1, , 000, 0, , x2, , x2 + 1, , x2 + x, , x2 + x + 1, , 100, , 101, , 110, , 111, , 0, 0, , x + x, , x2 + x + 1, , 111, , x + 1, , 110, , x2, , 100, 0, , 0, , x + 1, , 011, , 2, , 0, , x, , 010, , 101, , 0, , 1, , 001, , 2, , 0, , 0, , 000, , 0, , 001, , x + 1, , x + 1, , 011, , *, , x2 + x, , x, , x, , 010, , x2, , x2 + x + 1, , x + x, , 2, , x + 1, , 2, , x + 1, , x, , 1, , 0, , x2 + x + 1, , x2, , x2 + x, , 1, , x2 + 1, , x + x + 1, , 2, , x2 + 1, , x2, , x, , 1, , x + 1, , 2, , x2 + x, , x2 + x + 1, , x + 1, , 2, , x2 + 1, , x + 1, , x + x + 1, , x, , x2, , 1, , 0, x2 + 1, , 0, , x + 1, , 2, , 101, , x, , x + 1, , 0, , x2, , x, , (b) Multiplication, , x, , 1, , x, , 2, , x2 + x + 1, , x2 + x, , x, , x + 1, , 0, x + 1, , 0, , x + 1, , x, , 2, , 100, , x + 1, , x, , 1, , 1, , x2 + x, , x2 + x + 1, 0, , x2 + x + 1, , x2 + x, , (a) Addition, , 011, , x2, , x2 + 1, , x2 + x, , x2 + x + 1, , 0, , 1, , 010, , x2 + 1, , x2, , x2 + x + 1, , x2 + x, , 1, , x, x2 + 1, , 0, , x2, , x2 + 1, , x, , x + 1, , x + 1, , x, , x + 1, , x, , 2, , x + 1, , 2, , x, , x + 1, , 101, 2, , 2, , x, , 100, , 011, , 010, , x + 1, , 0, , 1, , 1, , 1, , 001, , 0, , 1, , 0, , 0, , +, , 001, , 000, , Polynomial Arithmetic Modulo (x3 + x + 1), , 000, , Table 5.3, , x2, , x, , x + 1, , x2 + 1, , 1, , x2 + x + 1, , x2 + x, , 0, , x + x, , 2, , 110, , 1, , 0, , x + 1, , x, , x2 + 1, , x2, , x2 + x + 1, , x + x, , 2, , x + x, , 110, 2, , 111, , 111, , 1, , x + 1, , x2, , x + x, , 2, , x, , x2 + 1, , x2 + x + 1, , 0, , x + x + 1, , 2, , 0, , 1, , x, , x + 1, , x2, , x2 + 1, , x2 + x, , x2 + x + 1, , x + x + 1, , 2, , 162, CHAPTER 5 / FINITE FIELDS
Page 166 :
5.6 / FINITE FIELDS OF THE FORM GF(2n), , 165, , A moment’s thought should convince you that Equation (5.4) is true; if you, are not sure, divide it out. In general, in GF(2n) with an nth-degree polynomial p(x),, we have xn mod p(x) = [p(x) - xn]., Now, consider a polynomial in GF(28), which has the form, f(x) = b7x7 + b6x6 + b5x5 + b4x4 + b3x3 + b2x2 + b1x + b0. If we multiply by x,, we have, x * f(x) = (b7x8 + b6x7 + b5x6 + b4x5 + b3x4, + b2x3 + b1x2 + b0x) mod m(x), , (5.5), , If b7 = 0, then the result is a polynomial of degree less than 8, which is already, in reduced form, and no further computation is necessary. If b7 = 1, then reduction, modulo m(x) is achieved using Equation (5.4):, x * f(x) = (b6x7 + b5x6 + b4x5 + b3x4 + b2x3 + b1x2 + b0x), + (x4 + x3 + x + 1), It follows that multiplication by x (i.e., 00000010) can be implemented as a 1-bit, left shift followed by a conditional bitwise XOR with (00011011), which represents, (x4 + x3 + x + 1). To summarize,, x * f(x) = b, , (b6b5b4b3b2b1b00), (b6b5b4b3b2b1b00) ⊕ (00011011), , if b7 = 0, if b7 = 1, , (5.6), , Multiplication by a higher power of x can be achieved by repeated application, of Equation (5.6). By adding intermediate results, multiplication by any constant in, GF(28) can be achieved., , In an earlier example, we showed that for f(x) = x6 + x4 + x2 + x + 1, g(x) = x7 +, x + 1, and m(x) = x8 + x4 + x3 + x + 1, we have f(x) * g(x) mod m(x) = x7 + x6 + 1., Redoing this in binary arithmetic, we need to compute (01010111) * (10000011). First,, we determine the results of multiplication by powers of x:, (01010111), (01010111), (01010111), (01010111), (01010111), (01010111), (01010111), , *, *, *, *, *, *, *, , (00000010), (00000100), (00001000), (00010000), (00100000), (01000000), (10000000), , =, =, =, =, =, =, =, , (10101110), (01011100) ⊕ (00011011) = (01000111), (10001110), (00011100) ⊕ (00011011) = (00000111), (00001110), (00011100), (00111000), , So,, (01010111) * (10000011) = (01010111) * [(00000001) ⊕ (00000010) ⊕ (10000000)], = (01010111) ⊕ (10101110) ⊕ (00111000) = (11000001), which is equivalent to x7 + x6 + 1.
Page 167 :
166, , CHAPTER 5 / FINITE FIELDS, , Using a Generator, An equivalent technique for defining a finite field of the form GF(2n), using the, same irreducible polynomial, is sometimes more convenient. To begin, we need two, definitions: A generator g of a finite field F of order q (contains q elements) is an, element whose first q - 1 powers generate all the nonzero elements of F. That is,, the elements of F consist of 0, g0, g1, c , gq - 2. Consider a field F defined by a, polynomial f(x). An element b contained in F is called a root of the polynomial if, f(b) = 0. Finally, it can be shown that a root g of an irreducible polynomial is a generator of the finite field defined on that polynomial., Let us consider the finite field GF(23), defined over the irreducible polynomial x3 + x + 1, discussed previously. Thus, the generator g must satisfy, f(g) = g3 + g + 1 = 0. Keep in mind, as discussed previously, that we need not, find a numerical solution to this equality. Rather, we deal with polynomial arithmetic in which arithmetic on the coefficients is performed modulo 2. Therefore,, the solution to the preceding equality is g3 = -g - 1 = g + 1. We now show, that g in fact generates all of the polynomials of degree less than 3. We have the, following., g4, g5, g6, g7, , =, =, =, =, , g(g3), g(g4), g(g5), g(g6), , =, =, =, =, , g(g + 1) = g2 + g, g(g2 + g) = g3 + g2 = g2 + g + 1, g(g2 + g + 1) = g3 + g2 + g = g2 + g + g + 1 = g2 + 1, g(g2 + 1) = g3 + g = g + g + 1 = 1 = g0, , We see that the powers of g generate all the nonzero polynomials in GF(23)., Also, it should be clear that gk = gk mod7 for any integer k. Table 5.5 shows the, power representation, as well as the polynomial and binary representations., , Generator for GF(23) using x3 + x + 1, , Table 5.5, , Power, Representation, , Polynomial, Representation, , Binary, Representation, , Decimal (Hex), Representation, , 0, , 0, , 000, , 0, , g 0( = g 7), , 1, , 001, , 1, , g1, , g, , 010, , 2, , g, , 2, , g, , 2, , 100, , 4, , g, , 3, , g + 1, , 011, , 3, , g, , 4, , g + g, , 110, , 6, , g, , 5, , g + g + 1, , 111, , 7, , g, , 6, , 101, , 5, , 2, , 2, , 2, , g + 1
Page 168 :
5.6 / FINITE FIELDS OF THE FORM GF(2n), , 167, , This power representation makes multiplication easy. To multiply in the, power notation, add exponents modulo 7. For example, g4 * g6 = g(10 mod 7) =, g3 = g + 1. The same result is achieved using polynomial arithmetic: We have, g4 = g2 + g and g6 = g2 + 1. Then, (g2 + g) * (g2 + 1) = g4 + g3 + g2 + g., Next, we need to determine (g4 + g3 + g2 + 1) mod (g3 + g + 1) by division:, g + 1, g + g + 1 g4 + g3 + g2 + g, g4 +, g2 + g, g3, g3 +, g + 1, g + 1, 3, , We get a result of g + 1, which agrees with the result obtained using the power, representation., Table 5.6 shows the addition and multiplication tables for GF(23) using, the power representation. Note that this yields the identical results to the, polynomial representation (Table 5.3) with some of the rows and columns, interchanged., , In general, for GF(2n) with irreducible polynomial f(x), determine, n, g = f(g) - gn. Then calculate all of the powers of g from gn + 1 through g2 - 2., 0, 2n - 2, The elements of the field correspond to the powers of g from g through g, plus the value 0. For multiplication of two elements in the field, use the equality, n, gk = gk mod(2 - 1) for any integer k., n, , Summary, In this section, we have shown how to construct a finite field of order 2n. Specifically,, we defined GF(2n) with the following properties., 1. GF(2n) consists of 2n elements., 2. The binary operations + and * are defined over the set. The operations, of addition, subtraction, multiplication, and division can be performed without leaving the set. Each element of the set other than 0 has a multiplicative, inverse., We have shown that the elements of GF(2n) can be defined as the set of all, polynomials of degree n - 1 or less with binary coefficients. Each such polynomial, can be represented by a unique n-bit value. Arithmetic is defined as polynomial, arithmetic modulo some irreducible polynomial of degree n. We have also seen that, an equivalent definition of a finite field GF(2n) makes use of a generator and that, arithmetic is defined using powers of the generator.
Page 169 :
g5, , g6, , 111, , 101, , 2, , 2, , g, g + 1, , 0, 0, 0, 0, , 2, , 3, , g, , g4, , 5, , g, , g, , g6, , 100, , 011, , 110, , 111, , 101, , 0, , g, , 0, , g, , 010, , g2 + 1, , g + g + 1, , g2 + g, , 1, , 0, , 1, , 001, , 0, , 1, , 0, 0, , 001, , 000, , 0, , g2, , g2 + g, , g2 + g + 1, , g2 + 1, , g2 + g + 1, , g2 + g, , 000, , *, , g4, , 110, , 2, , 1, , g + 1, , 2, , g2 + g + 1, , g + g, , 2, , g + 1, , g + g, , g2 + g, , g2, , g, , (b) Multiplication, , g, 1, , g + 1, , g, , 2, , g2 + g, , g + 1, , g2, , g, , g2 + g + 1, , g2 + g, , g + 1, , g2, , g, 1, , 1, , g2 + 1, , 0, , g6, , 101, , g, , g + 1, , 2, , g2 + g + 1, , 0, , g, , 5, , 1, g + 1, , 2, , g + g + 1, , 2, , 0, , 1, , g + 1, , 2, , g + g + 1, , 2, , 2, , g + 1, , 0, , g, , 4, , 111, , 0, , g, , g + 1, , 110, , g, , g + 1, , g2 + g, , 0, , 1, , g2, , 1, , g2 + g + 1, , g2, , g2 + 1, , g6, , 101, , 1, , 0, , g2 + 1, , g + 1, , g, , g2 + 1, , g + g + 1, , g + g, , g + 1, , 2, , 2, , g2, , G, g, , 0, , g, , 3, , 011, , (a) Addition, , 0, , g, , 100, , G, , 2, , g2, , g + 1, g2 + g, , g2 + 1, , g, , 1, , 0, , g2 + g + 1, , g2 + g + 1, , 0, , g2 + 1, , g2 + g, , g2 + g + 1, , g, , 5, , 111, , g2, , g2 + g + 1, , g, 1, , g2 + g, , g + 1, , g2 + g, , 010, , g2 + g + 1, , g2 + 1, , g2, , 1, , g, , g + 1, , g3, , 011, , 0, , g2 + 1, , g + 1, , g2 + g, , g2, , 100, , g + 1, , g2, , G, , g2 + 1, , g, , g, , 010, , 0, , 1, , g, , G, g, , 4, , 3, , 2, , g, , 110, , 011, , 100, , 010, , g2, , 1, , 1, , 001, , 0, , 1, , 0, , 0, , +, , 001, , 000, , GF(23) Arithmetic Using Generator for the Polynomial (x3 + x + 1), , 000, , Table 5.6, , 168, CHAPTER 5 / FINITE FIELDS
Page 170 :
5.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 169, , 5.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, order, polynomial, polynomial arithmetic, polynomial ring, prime number, prime polynomial, relatively prime, residue, ring, , greatest common divisor, group, identity element, infinite field, infinite group, integral domain, inverse element, irreducible polynomial, modular arithmetic, modular polynomial, arithmetic, monic polynomial, , abelian group, associative, coefficient set, commutative, commutative ring, cyclic group, divisor, Euclidean algorithm, field, finite field, finite group, generator, , Review Questions, 5.1, 5.2, 5.3, 5.4, , Briefly define a group., Briefly define a ring., Briefly define a field., List three classes of polynomial arithmetic., , Problems, 5.1, , 5.2, , 5.3, , 5.4, 5.5, 5.6, , For the group Sn of all permutations of n distinct symbols,, a. what is the number of elements in Sn?, b. show that Sn is not abelian for n 7 2., Does the set of residue classes (mod3) form a group, a. with respect to modular addition?, b. with respect to modular multiplication?, Let S = {0, a, b, c}. The addition and multiplication on the set S is defined in the, following tables:, +, , 0, , a, , B, , C, , *, , 0, , a, , b, , c, , 0, , 0, , a, , B, , C, , 0, , 0, , 0, , 0, , 0, , A, , a, , 0, , c, , B, , a, , 0, , a, , b, , c, , B, , b, , c, , 0, , A, , b, , 0, , a, , b, , c, , C, , c, , b, , a, , 0, , c, , 0, , 0, , 0, , 0, , Is S a noncommutative ring? Justify your answer., Develop a set of tables similar to Table 5.1 for GF(5)., Demonstrate that the set of polynomials whose coefficients form a field is a ring., Demonstrate whether each of these statements is true or false for polynomials over a, field.
Page 171 :
170, , CHAPTER 5 / FINITE FIELDS, , 5.7, , 5.8, , 5.9, , 5.10, 5.11, 5.12, , a. The product of monic polynomials is monic., b. The product of polynomials of degrees m and n has degree m + n., c. The sum of polynomials of degrees m and n has degree max [m, n]., For polynomial arithmetic with coefficients in Z1 1 , perform the following calculations., a. (x 2 + 2 x + 9 )(x 3 + 1 1 x 2 + x + 7 ), b. (8 x 2 + 3 x + 2 )(5 x 2 + 6 ), Determine which of the following polynomials are reducible over GF(2)., a. x 2 + 1, b. x 2 + x + 1, c. x 4 + x + 1, Determine the gcd of the following pairs of polynomials., a. (x3 + 1) and (x2 + x + 1) over GF(2), b. (x3 + x + 1) and (x2 + 1) over GF(3), c. (x3 - 2x + 1) and (x2 - x - 2) over GF(5), d. (x4 + 8x3 + 7x + 8) and (2x3 + 9x2 + 10x + 1) over GF(11), Develop a set of tables similar to Table 5.3 for GF(3) with m(x) = x2 + x + 1., Determine the multiplicative inverse of x 2 + 1 in GF(2 3 ) with m (x ) = x 3 + x - 1 ., Develop a table similar to Table 5.5 for GF(2 5 ) with m (x ) = x 5 + x 4 + x 3 + x + 1 ., , Programming Problems, 5.13, 5.14, , Write a simple four-function calculator in GF(24). You may use table lookups for the, multiplicative inverses., Write a simple four-function calculator in GF(28). You should compute the multiplicative inverses on the fly.
Page 172 :
CHAPTER, , Advanced Encryption Standard, 6.1, , Finite Field Arithmetic, , 6.2, , AES Structure, General Structure, Detailed Structure, , 6.3, , AES Transformation Functions, Substitute Bytes Transformation, ShiftRows Transformation, MixColumns Transformation, AddRoundKey Transformation, , 6.4, , AES Key Expansion, Key Expansion Algorithm, Rationale, , 6.5, , An AES Example, Results, Avalanche Effect, , 6.6, , AES Implementation, Equivalent Inverse Cipher, Implementation Aspects, , 6.7, , Key Terms, Review Questions, and Problems, , Appendix 6A Polynomials with Coefficients in GF(28), , 171
Page 173 :
172, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Present an overview of the general structure of Advanced Encryption, Standard (AES)., ◆ Understand the four transformations used in AES., ◆ Explain the AES key expansion algorithm., ◆ Understand the use of polynomials with coefficients in GF(28)., , The Advanced Encryption Standard (AES) was published by the National Institute of, Standards and Technology (NIST) in 2001. AES is a symmetric block cipher that is, intended to replace DES as the approved standard for a wide range of applications., Compared to public-key ciphers such as RSA, the structure of AES and most symmetric ciphers is quite complex and cannot be explained as easily as many other, cryptographic algorithms. Accordingly, the reader may wish to begin with a simplified, version of AES, which is described in Appendix I. This version allows the reader to, perform encryption and decryption by hand and gain a good understanding of the, working of the algorithm details. Classroom experience indicates that a study of this, simplified version enhances understanding of AES.1 One possible approach is to read, the chapter first, then carefully read Appendix I, and then re-read the main body, of the chapter., Appendix H looks at the evaluation criteria used by NIST to select from among, the candidates for AES, plus the rationale for picking Rijndael, which was the winning, candidate. This material is useful in understanding not just the AES design but also the, criteria by which to judge any symmetric encryption algorithm., , 6.1 FINITE FIELD ARITHMETIC, In AES, all operations are performed on 8-bit bytes. In particular, the arithmetic, operations of addition, multiplication, and division are performed over the finite, field GF(28). Section 5.6 discusses such operations in some detail. For the reader, who has not studied Chapter 5, and as a quick review for those who have, this section summarizes the important concepts., In essence, a field is a set in which we can do addition, subtraction, multiplication, and division without leaving the set. Division is defined with the following rule:, a/b = a(b-1). An example of a finite field (one with a finite number of elements) is, the set Z p consisting of all the integers {0, 1, c , p - 1}, where p is a prime number and in which arithmetic is carried out modulo p., 1, , However, you may safely skip Appendix I, at least on a first reading. If you get lost or bogged down in, the details of AES, then you can go back and start with simplified AES., , Hiva-Network.Com
Page 174 :
6.1 / FINITE FIELD ARITHMETIC, , 173, , Virtually all encryption algorithms, both conventional and public-key, involve, arithmetic operations on integers. If one of the operations used in the algorithm, is division, then we need to work in arithmetic defined over a field; this is because, division requires that each nonzero element have a multiplicative inverse. For convenience and for implementation efficiency, we would also like to work with integers that fit exactly into a given number of bits, with no wasted bit patterns. That is,, we wish to work with integers in the range 0 through 2n - 1, which fit into an n-bit, word. Unfortunately, the set of such integers, Z2n, using modular arithmetic, is not a, field. For example, the integer 2 has no multiplicative inverse in Z2n, that is, there is, no integer b, such that 2b mod 2n = 1., There is a way of defining a finite field containing 2n elements; such a field is, referred to as GF(2n). Consider the set, S, of all polynomials of degree n - 1 or less, with binary coefficients. Thus, each polynomial has the form, n-1, , f(x) = an - 1xn - 1 + an - 2xn - 2 + g + a1x + a0 = a aixi, i=0, , where each ai takes on the value 0 or 1. There are a total of 2n different polynomials, in S. For n = 3, the 23 = 8 polynomials in the set are, 0, 1, , x, x + 1, , x2, x2 + 1, , x2 + x, x2 + x + 1, , With the appropriate definition of arithmetic operations, each such set S is a, finite field. The definition consists of the following elements., 1. Arithmetic follows the ordinary rules of polynomial arithmetic using the basic, rules of algebra with the following two refinements., 2. Arithmetic on the coefficients is performed modulo 2. This is the same as the, XOR operation., 3. If multiplication results in a polynomial of degree greater than n - 1, then the, polynomial is reduced modulo some irreducible polynomial m(x) of degree n., That is, we divide by m(x) and keep the remainder. For a polynomial f(x),, the remainder is expressed as r(x) = f(x) mod m(x). A polynomial m(x) is, called irreducible if and only if m(x) cannot be expressed as a product of two, polynomials, both of degree lower than that of m(x)., For example, to construct the finite field GF(23), we need to choose an irreducible polynomial of degree 3. There are only two such polynomials: (x3 + x2 + 1), and (x3 + x + 1). Addition is equivalent to taking the XOR of like terms. Thus,, (x + 1) + x = 1., A polynomial in GF(2n) can be uniquely represented by its n binary coefficients, (an - 1an - 2 c a0). Therefore, every polynomial in GF(2n) can be represented by, an n-bit number. Addition is performed by taking the bitwise XOR of the two n-bit, elements. There is no simple XOR operation that will accomplish multiplication in, GF(2n). However, a reasonably straightforward, easily implemented, technique is, available. In essence, it can be shown that multiplication of a number in GF(2n) by
Page 175 :
174, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , 2 consists of a left shift followed by a conditional XOR with a constant. Multiplication, by larger numbers can be achieved by repeated application of this rule., For example, AES uses arithmetic in the finite field GF(28) with the irreducible, polynomial m(x) = x8 + x4 + x3 + x + 1. Consider two elements A =, (a7a6 c a1a0) and B = (b7b6 c b1b0). The sum A + B = (c7c6 c c1c0), where, ci = ai ⊕ bi. The multiplication {02} # A equals (a6 c a1a00) if a7 = 0 and equals, (a6 c a1a00) ⊕ (00011011) if a7 = 1.2, To summarize, AES operates on 8-bit bytes. Addition of two bytes is defined, as the bitwise XOR operation. Multiplication of two bytes is defined as multiplication in the finite field GF(28), with the irreducible polynomial3 m(x) = x8 + x4 + x3 +, x + 1. The developers of Rijndael give as their motivation for selecting this one of, the 30 possible irreducible polynomials of degree 8 that it is the first one on the list, given in [LIDL94]., , 6.2 AES STRUCTURE, General Structure, Figure 6.1 shows the overall structure of the AES encryption process. The cipher, takes a plaintext block size of 128 bits, or 16 bytes. The key length can be 16, 24, or, 32 bytes (128, 192, or 256 bits). The algorithm is referred to as AES-128, AES-192,, or AES-256, depending on the key length., The input to the encryption and decryption algorithms is a single 128-bit block., In FIPS PUB 197, this block is depicted as a 4 * 4 square matrix of bytes. This, block is copied into the State array, which is modified at each stage of encryption or, decryption. After the final stage, State is copied to an output matrix. These operations are depicted in Figure 6.2a. Similarly, the key is depicted as a square matrix of, bytes. This key is then expanded into an array of key schedule words. Figure 6.2b, shows the expansion for the 128-bit key. Each word is four bytes, and the total key, schedule is 44 words for the 128-bit key. Note that the ordering of bytes within a matrix is by column. So, for example, the first four bytes of a 128-bit plaintext input to, the encryption cipher occupy the first column of the in matrix, the second four bytes, occupy the second column, and so on. Similarly, the first four bytes of the expanded, key, which form a word, occupy the first column of the w matrix., The cipher consists of N rounds, where the number of rounds depends on the, key length: 10 rounds for a 16-byte key, 12 rounds for a 24-byte key, and 14 rounds, for a 32-byte key (Table 6.1). The first N - 1 rounds consist of four distinct transformation functions: SubBytes, ShiftRows, MixColumns, and AddRoundKey,, which are described subsequently. The final round contains only three transformations, and there is a initial single transformation (AddRoundKey) before the first, round, which can be considered Round 0. Each transformation takes one or more, , 2, , In FIPS PUB 197, a hexadecimal number is indicated by enclosing it in curly brackets. We use that convention, in this chapter., 3, In the remainder of this discussion, references to GF(28) refer to the finite field defined with this, polynomial.
Page 176 :
6.2 / AES STRUCTURE, Plaintext—16 bytes (128 bits), , Input state, (16 bytes), , 175, , Key—M bytes, , Round 0 key, (16 bytes), , Key, (M bytes), , Initial transformation, , Round 1, (4 transformations), , Round 1 key, (16 bytes), , Round 1, output state, (16 bytes), , Round N – 1, (4 transformations), , Key expansion, , State after, initial, transformation, (16 bytes), , Round N – 1 key, (16 bytes), , Round N – 1, output state, (16 bytes), Round N, (3 transformations), , Round N key, (16 bytes), , Final state, (16 bytes), , Cipehertext—16 bytes (128 bits), , No. of, rounds, , Key, Length, (bytes), , 10, , 16, , 12, , 24, , 14, , 32, , Figure 6.1 AES Encryption Process, , 4 * 4 matrices as input and produces a 4 * 4 matrix as output. Figure 6.1 shows, that the output of each round is a 4 * 4 matrix, with the output of the final round, being the ciphertext. Also, the key expansion function generates N + 1 round keys,, each of which is a distinct 4 * 4 matrix. Each round key serves as one of the inputs, to the AddRoundKey transformation in each round.
Page 178 :
6.2 / AES STRUCTURE, , 177, , Table 6.1 AES Parameters, Key Size (words/bytes/bits), Plaintext Block Size (words/bytes/bits), Number of Rounds, Round Key Size (words/bytes/bits), Expanded Key Size (words/bytes), , 4/16/128, 4/16/128, 10, 4/16/128, 44/176, , 6/24/192, 4/16/128, 12, 4/16/128, 52/208, , 8/32/256, 4/16/128, 14, 4/16/128, 60/240, , Detailed Structure, Figure 6.3 shows the AES cipher in more detail, indicating the sequence of transformations in each round and showing the corresponding decryption function. As was, done in Chapter 4, we show encryption proceeding down the page and decryption, proceeding up the page., Before delving into details, we can make several comments about the overall, AES structure., 1. One noteworthy feature of this structure is that it is not a Feistel structure., Recall that, in the classic Feistel structure, half of the data block is used to, modify the other half of the data block and then the halves are swapped. AES, instead processes the entire data block as a single matrix during each round, using substitutions and permutation., 2. The key that is provided as input is expanded into an array of forty-four 32-bit, words, w[i]. Four distinct words (128 bits) serve as a round key for each round;, these are indicated in Figure 6.3., 3. Four different stages are used, one of permutation and three of substitution:, ■ Substitute bytes: Uses an S-box to perform a byte-by-byte substitution of, the block., ■ ShiftRows: A simple permutation., ■ MixColumns: A substitution that makes use of arithmetic over GF(28)., ■ AddRoundKey: A simple bitwise XOR of the current block with a portion, of the expanded key., 4. The structure is quite simple. For both encryption and decryption, the cipher, begins with an AddRoundKey stage, followed by nine rounds that each includes all four stages, followed by a tenth round of three stages. Figure 6.4, depicts the structure of a full encryption round., 5. Only the AddRoundKey stage makes use of the key. For this reason, the cipher, begins and ends with an AddRoundKey stage. Any other stage, applied at the, beginning or end, is reversible without knowledge of the key and so would add, no security., 6. The AddRoundKey stage is, in effect, a form of Vernam cipher and by itself, would not be formidable. The other three stages together provide confusion,, diffusion, and nonlinearity, but by themselves would provide no security because they do not use the key. We can view the cipher as alternating operations, of XOR encryption (AddRoundKey) of a block, followed by scrambling of the
Page 179 :
Key, (16 bytes), Expand key, , Plaintext, (16 bytes), , Add round key, , w[0, 3], , Add round key, , Substitute bytes, , Inverse sub bytes, , Shift rows, , Inverse shift rows, , Mix columns, , Inverse mix cols, w[4, 7], , Inverse sub bytes, , ,, ,, ,, , Inverse shift rows, , Substitute bytes, , Round 9, , Add round key, , Shift rows, , ., ., ., , Mix columns, , Inverse mix cols, , Add round key, , w[36, 39], , Add round key, , Substitute bytes, , Inverse sub bytes, , Shift rows, , Inverse shift rows, , Add round key, , Round 9, , Add round key, , Round 10, , Plaintext, (16 bytes), , w[40, 43], , Round 1, , Round 1, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , Round 10, , 178, , Add round key, , Ciphertext, (16 bytes), , Ciphertext, (16 bytes), , (a) Encryption, , (b) Decryption, , Figure 6.3 AES Encryption and Decryption, , block (the other three stages), followed by XOR encryption, and so on. This, scheme is both efficient and highly secure., 7. Each stage is easily reversible. For the Substitute Byte, ShiftRows, and, MixColumns stages, an inverse function is used in the decryption algorithm., For the AddRoundKey stage, the inverse is achieved by XORing the same, round key to the block, using the result that A ⊕ B ⊕ B = A., 8. As with most block ciphers, the decryption algorithm makes use of the, expanded key in reverse order. However, the decryption algorithm is not
Page 180 :
6.3 / AES TRANSFORMATION FUNCTIONS, , 179, , State, , S, , SubBytes, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , S, , State, , ShiftRows, , State, , MixColumns, , M, , M, , M, , M, , State, r0, , r1, , r2, , r3, , r4, , r5, , r6, , r7, , r8, , r9, , r10, , r11, , r12, , r13, , r14, , r15, , AddRoundKey, , State, , Figure 6.4 AES Encryption Round, , identical to the encryption algorithm. This is a consequence of the particular, structure of AES., 9. Once it is established that all four stages are reversible, it is easy to verify, that decryption does recover the plaintext. Figure 6.3 lays out encryption, and decryption going in opposite vertical directions. At each horizontal point, (e.g., the dashed line in the figure), State is the same for both encryption and, decryption., 10. The final round of both encryption and decryption consists of only three stages., Again, this is a consequence of the particular structure of AES and is required, to make the cipher reversible., , 6.3 AES TRANSFORMATION FUNCTIONS, We now turn to a discussion of each of the four transformations used in AES. For, each stage, we describe the forward (encryption) algorithm, the inverse (decryption), algorithm, and the rationale for the stage.
Page 183 :
182, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , Here is an example of the SubBytes transformation:, EA, , 04, , 65, , 85, , 87, , F2, , 4D, , 97, , 83, , 45, , 5D, , 96, , EC, , 6E, , 4C, , 90, , 5C, , 33, , 98, , B0, , F0, , 2D, , AD, , C5, , S, , 4A, , C3, , 46, , E7, , 8C, , D8, , 95, , A6, , The S-box is constructed in the following fashion (Figure 6.6a)., , Byte at row y,, column x, initialized to yx, , Byte at row y,, column x, initialized to yx, , yx, , Inverse, in GF(28), , Byte to bit, column vector, , 0, 0, 1, 1, 1, 1, 1, 0, , 0, 0, 0, 1, 1, 1, 1, 1, , 1, 0, 0, 0, 1, 1, 1, 1, , 1, 1, 0, 0, 0, 1, 1, 1, , 1, 1, 1, 0, 0, 0, 1, 1, , 0, 1, 0, b2¿, 1, b3¿, =, 0, b4¿, 0, b5¿, 1, b6¿, 0, b7¿, b0¿, b1¿, , Byte to bit, column vector, , 1 0, b0¿, 1 1, b1¿, 1 1, b2¿, 1 1, b3¿, =, 1 1, b4¿, 0 1, b5¿, 0 0, b6¿, 0 0, b7¿, , yx, , 1, 1, 1, 1, 0, 0, 0, 1, , b0, , 1, b1, 1, b2, 0, b3, 0, +, b4, 0, b5, 1, b6, 1, b7, 0, , 0, 0, 1, 0, 1, 0, 0, 1, , 1, 0, 0, 1, 0, 1, 0, 0, , 0, 1, 0, 0, 1, 0, 1, 0, , 0, 0, 1, 0, 0, 1, 0, 1, , 1, 0, 0, 1, 0, 0, 1, 0, , 0, 1, 0, 0, 1, 0, 0, 1, , 1, 0, 1, 0, 0, 1, 0, 0, , b0, , 1, b1, 0, b2, 1, b3, 0, +, b4, 0, b5, 0, b6, 0, b7, 0, , Bit column, vector to byte, , Bit column, vector to byte, , Inverse, in GF(28), , S(yx), , IS(yx), , (a) Calculation of byte at, row y, column x of S-box, , (a) Calculation of byte at, row y, column x of IS-box, , Figure 6.6, , Constuction of S-Box and IS-Box
Page 184 :
6.3 / AES TRANSFORMATION FUNCTIONS, , 183, , 1. Initialize the S-box with the byte values in ascending sequence row by row., The first row contains {00}, {01}, {02}, c , {0F}; the second row contains, {10}, {11}, etc.; and so on. Thus, the value of the byte at row y, column x is {yx}., 2. Map each byte in the S-box to its multiplicative inverse in the finite field, GF(28); the value {00} is mapped to itself., 3. Consider that each byte in the S-box consists of 8 bits labeled, (b7, b6, b5, b4, b3, b2, b1, b0). Apply the following transformation to each bit of, each byte in the S-box:, bi= = bi ⊕ b(i + 4) mod 8 ⊕ b(i + 5) mod 8 ⊕ b(i + 6) mod 8 ⊕ b(i + 7) mod 8 ⊕ ci (6.1), where ci is the ith bit of byte c with the value {63}; that is,, (c7c6c5c4c3c2c1c0) = (01100011). The prime (′) indicates that the variable is to, be updated by the value on the right. The AES standard depicts this transformation in matrix form as follows., b0=, 1, b1=, 1, =, b2, 1, b3=, 1, H =X = H, b4, 1, b5=, 0, b6=, 0, b7=, 0, , 0, 1, 1, 1, 1, 1, 0, 0, , 0, 0, 1, 1, 1, 1, 1, 0, , 0, 0, 0, 1, 1, 1, 1, 1, , 1, 0, 0, 0, 1, 1, 1, 1, , 1, 1, 0, 0, 0, 1, 1, 1, , 1, 1, 1, 0, 0, 0, 1, 1, , 1, b0, 1, 1, b1, 1, 1, b2, 0, 1, b3, 0, XH X + H X, 0, b4, 0, 0, b5, 1, 0, b6, 1, 1, b7, 0, , (6.2), , Equation (6.2) has to be interpreted carefully. In ordinary matrix multiplication,4 each element in the product matrix is the sum of products of the elements of, one row and one column. In this case, each element in the product matrix is the, bitwise XOR of products of elements of one row and one column. Furthermore, the, final addition shown in Equation (6.2) is a bitwise XOR. Recall from Section 5.6, that the bitwise XOR is addition in GF(28)., As an example, consider the input value {95}. The multiplicative inverse in, GF(28) is {95}-1 = {8A}, which is 10001010 in binary. Using Equation (6.2),, 1, 1, 1, 1, H, 1, 0, 0, 0, 4, , 0, 1, 1, 1, 1, 1, 0, 0, , 0, 0, 1, 1, 1, 1, 1, 0, , 0, 0, 0, 1, 1, 1, 1, 1, , 1, 0, 0, 0, 1, 1, 1, 1, , 1, 1, 0, 0, 0, 1, 1, 1, , 1, 1, 1, 0, 0, 0, 1, 1, , 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 0, 1, 0, 1, XH X ⊕ H X = H X ⊕ H X = H X, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 0, , For a brief review of the rules of matrix and vector multiplication, refer to Appendix E.
Page 185 :
184, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , The result is {2A}, which should appear in row {09} column {05} of the S-box., This is verified by checking Table 6.2a., The inverse substitute byte transformation, called InvSubBytes, makes use, of the inverse S-box shown in Table 6.2b. Note, for example, that the input {2A}, produces the output {95}, and the input {95} to the S-box produces {2A}. The inverse, S-box is constructed (Figure 6.6b) by applying the inverse of the transformation in, Equation (6.1) followed by taking the multiplicative inverse in GF(28). The inverse, transformation is, bi= = b(i + 2) mod 8 ⊕ b(i + 5) mod 8 ⊕ b(i + 7) mod 8 ⊕ d i, where byte d = {05}, or 00000101. We can depict this transformation as follows., 0, b0=, b1=, 1, =, b2, 0, b3=, 1, H =X = H, b4, 0, b5=, 0, b6=, 1, b7=, 0, , 0, 0, 1, 0, 1, 0, 0, 1, , 1, 0, 0, 1, 0, 1, 0, 0, , 0, 1, 0, 0, 1, 0, 1, 0, , 0, 0, 1, 0, 0, 1, 0, 1, , 1, 0, 0, 1, 0, 0, 1, 0, , 1, b0, 1, 0, b1, 0, 1, b2, 1, 0, b3, 0, XH X + H X, 0, b4, 0, 1, b5, 0, 0, b6, 0, 0, b7, 0, , 0, 1, 0, 0, 1, 0, 0, 1, , To see that InvSubBytes is the inverse of SubBytes, label the matrices in, SubBytes and InvSubBytes as X and Y, respectively, and the vector versions of constants c and d as C and D, respectively. For some 8-bit vector B, Equation (6.2), becomes B= = XB ⊕ C. We need to show that Y(XB ⊕ C) ⊕ D = B. To multiply, out, we must show YXB ⊕ YC ⊕ D = B. This becomes, 0, 1, 0, 1, H, 0, 0, 1, 0, , 0, 0, 1, 0, 1, 0, 0, 1, , 1, 0, 0, 1, 0, 1, 0, 0, , 0, 1, 0, 0, 1, 0, 1, 0, , 0, 0, 1, 0, 0, 1, 0, 1, , 1, 0, 0, 1, 0, 0, 1, 0, , 0, 1, 0, 0, 1, 0, 0, 1, , 1, 1, 0, 1, 1, 1, 0, 1, XH, 0, 1, 1, 0, 0, 0, 0, 0, , 0, 1, 1, 1, 1, 1, 0, 0, , 0, 0, 1, 1, 1, 1, 1, 0, , 0, 1, 0, 1, H, 0, 0, 1, 0, , 0, 0, 1, 0, 1, 0, 0, 1, , 1, 0, 0, 1, 0, 1, 0, 0, , 0, 1, 0, 0, 1, 0, 1, 0, , 0, 0, 1, 0, 0, 1, 0, 1, , 0, 1, 0, 0, 1, 0, 0, 1, , 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, XH X ⊕ H X =, 0, 0, 0, 1, 1, 0, 0, 1, 0, 0, 0, 0, , 1, 0, 0, 1, 0, 0, 1, 0, , 0, 0, 0, 1, 1, 1, 1, 1, , 1, 0, 0, 0, 1, 1, 1, 1, , 1, 1, 0, 0, 0, 1, 1, 1, , 1, 1, 1, 0, 0, 0, 1, 1, , 1, b0, 1, b1, 1, b2, 1, b, X H 3X ⊕, 0, b4, 0, b5, 0, b6, 1, b7
Page 186 :
6.3 / AES TRANSFORMATION FUNCTIONS, , 1, 0, 0, 0, H, 0, 0, 0, 0, , 0, 1, 0, 0, 0, 0, 0, 0, , 0, 0, 1, 0, 0, 0, 0, 0, , 0, 0, 0, 1, 0, 0, 0, 0, , 0, 0, 0, 0, 1, 0, 0, 0, , 0, 0, 0, 0, 0, 1, 0, 0, , 0, 0, 0, 0, 0, 0, 1, 0, , 185, , 0, b0, 1, 1, b0, 0, b1, 0, 0, b1, 0, b2, 1, 1, b2, 0, b3, 0, 0, b, X H X ⊕ H X ⊕ H X = H 3X, 0, b4, 0, 0, b4, 0, b5, 0, 0, b5, b6, b6, 0, 0, 0, b7, b7, 1, 0, 0, , We have demonstrated that YX equals the identity matrix, and the YC = D,, so that YC ⊕ D equals the null vector., RATIONALE The S-box is designed to be resistant to known cryptanalytic attacks., Specifically, the Rijndael developers sought a design that has a low correlation, between input bits and output bits and the property that the output is not a linear, mathematical function of the input [DAEM01]. The nonlinearity is due to the use, of the multiplicative inverse. In addition, the constant in Equation (6.1) was chosen, so that the S-box has no fixed points [S@box(a) = a] and no “opposite fixed points”, [S@box(a) = a], where a is the bitwise complement of a., Of course, the S-box must be invertible, that is, IS@box[S@box(a)] = a., However, the S-box does not self-inverse in the sense that it is not true that, S@box(a) = IS@box(a). For example, S@box({95}) = {2A}, but IS@box({95}) = {AD}., , ShiftRows Transformation, FORWARD AND INVERSE TRANSFORMATIONS The forward shift row transformation,, called ShiftRows, is depicted in Figure 6.7a. The first row of State is not altered. For, the second row, a 1-byte circular left shift is performed. For the third row, a 2-byte, circular left shift is performed. For the fourth row, a 3-byte circular left shift is performed. The following is an example of ShiftRows., 87, , F2, , 4D, , 97, , 87, , F2, , 4D, , 97, , EC, , 6E, , 4C, , 90, , 6E, , 4C, , 90, , EC, , 4A, , C3, , 46, , E7, , 46, , E7, , 4A, , C3, , 8C, , D8, , 95, , A6, , A6, , 8C, , D8, , 95, , S, , The inverse shift row transformation, called InvShiftRows, performs the circular shifts in the opposite direction for each of the last three rows, with a 1-byte, circular right shift for the second row, and so on., RATIONALE The shift row transformation is more substantial than it may first, appear. This is because the State, as well as the cipher input and output, is, treated as an array of four 4-byte columns. Thus, on encryption, the first 4 bytes, of the plaintext are copied to the first column of State, and so on. Furthermore,, as will be seen, the round key is applied to State column by column. Thus, a row, shift moves an individual byte from one column to another, which is a linear
Page 190 :
6.3 / AES TRANSFORMATION FUNCTIONS, , 189, , each column as a four-term polynomial and multiplying each column by b(x),, given by, b(x) = {0B}x3 + {0D}x2 + {09}x + {0E}, , (6.8), , It readily can be shown that b(x) = a -1(x) mod (x4 + 1)., RATIONALE The coefficients of the matrix in Equation (6.3) are based on a linear, code with maximal distance between code words, which ensures a good mixing, among the bytes of each column. The mix column transformation combined with, the shift row transformation ensures that after a few rounds all output bits depend, on all input bits. See [DAEM99] for a discussion., In addition, the choice of coefficients in MixColumns, which are all {01}, {02},, or {03}, was influenced by implementation considerations. As was discussed, multiplication by these coefficients involves at most a shift and an XOR. The coefficients, in InvMixColumns are more formidable to implement. However, encryption was, deemed more important than decryption for two reasons:, 1. For the CFB and OFB cipher modes (Figures 7.5 and 7.6; described in, Chapter 7), only encryption is used., 2. As with any block cipher, AES can be used to construct a message authentication code (Chapter 13), and for this, only encryption is used., , AddRoundKey Transformation, FORWARD AND INVERSE TRANSFORMATIONS In the forward add round key transformation, called AddRoundKey, the 128 bits of State are bitwise XORed with the, 128 bits of the round key. As shown in Figure 6.5b, the operation is viewed as a, columnwise operation between the 4 bytes of a State column and one word of, the round key; it can also be viewed as a byte-level operation. The following is an, example of AddRoundKey:, 47, , 40, , A3, , 4C, , AC, , 19, , 28, , 57, , EB, , 59, , 8B, , 1B, , 37, , D4, , 70, , 9F, , 77, , FA, , D1, , 5C, , 40, , 2E, , A1, , C3, , 94, , E4, , 3A, , 42, , 66, , DC, , 29, , 00, , ED A5, , A6, , BC, , F3, , 21, , 41, , 6A, , ⊕, , =, , F2, , 38, , 13, , 42, , 1E, , 84, , E7, , D6, , The first matrix is State, and the second matrix is the round key., The inverse add round key transformation is identical to the forward add, round key transformation, because the XOR operation is its own inverse., RATIONALE The add round key transformation is as simple as possible and affects, every bit of State. The complexity of the round key expansion, plus the complexity, of the other stages of AES, ensure security., Figure 6.8 is another view of a single round of AES, emphasizing the mechanisms and inputs of each transformation.
Page 191 :
190, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, State matrix, at beginning, of round, SubBytes, , S-box, , ShiftRows, , 02, 01, 01, 03, , 03, 02, 01, 01, , 01, 03, 02, 01, , 01, 01, 03, 02, , MixColumns, , MixColumns matrix, Round, key, AddRoundKey, State matrix, at end, of round, Constant inputs, , Figure 6.8, , Variable input, , Inputs for Single AES Round, , 6.4 AES KEY EXPANSION, Key Expansion Algorithm, The AES key expansion algorithm takes as input a four-word (16-byte) key and, produces a linear array of 44 words (176 bytes). This is sufficient to provide a fourword round key for the initial AddRoundKey stage and each of the 10 rounds of the, cipher. The pseudocode on the next page describes the expansion., The key is copied into the first four words of the expanded key. The remainder of the expanded key is filled in four words at a time. Each added word w[i], depends on the immediately preceding word, w[i - 1], and the word four positions, back, w[i - 4]. In three out of four cases, a simple XOR is used. For a word whose, position in the w array is a multiple of 4, a more complex function is used. Figure 6.9, illustrates the generation of the expanded key, using the symbol g to represent that, complex function. The function g consists of the following subfunctions., , Hiva-Network.Com
Page 193 :
192, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , 1. RotWord performs a one-byte circular left shift on a word. This means that an, input word [B 0, B 1, B 2, B 3] is transformed into [B 1, B 2, B 3, B 0]., 2. SubWord performs a byte substitution on each byte of its input word, using the, S-box (Table 6.2a)., 3. The result of steps 1 and 2 is XORed with a round constant, Rcon[j]., The round constant is a word in which the three rightmost bytes are always 0., Thus, the effect of an XOR of a word with Rcon is to only perform an XOR on the, leftmost byte of the word. The round constant is different for each round and is defined as Rcon[j] = (RC[j], 0, 0, 0), with RC[1] = 1, RC[j] = 2 # RC[j - 1] and with, multiplication defined over the field GF(28). The values of RC[j] in hexadecimal are, j, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9, , 10, , RC[j], , 01, , 02, , 04, , 08, , 10, , 20, , 40, , 80, , 1B, , 36, , For example, suppose that the round key for round 8 is, EA D2 73 21 B5 8D BA D2 31 2B F5 60 7F 8D 29 2F, Then the first 4 bytes (first column) of the round key for round 9 are calculated as, follows:, i (decimal), 36, , temp, , After, RotWord, , After, SubWord, , Rcon (9), , After XOR, with Rcon, , w[i - 4], , w[i] = temp, ⊕ w[i - 4], , 7F8D292F 8D292F7F 5DA515D2 1B000000 46A515D2 EAD27321 AC7766F3, , Rationale, The Rijndael developers designed the expansion key algorithm to be resistant to, known cryptanalytic attacks. The inclusion of a round-dependent round constant, eliminates the symmetry, or similarity, between the ways in which round keys are, generated in different rounds. The specific criteria that were used are [DAEM99], ■, ■, , ■, ■, ■, ■, ■, , Knowledge of a part of the cipher key or round key does not enable calculation of many other round-key bits., An invertible transformation [i.e., knowledge of any Nk consecutive words of, the expanded key enables regeneration of the entire expanded key (Nk = key, size in words)]., Speed on a wide range of processors., Usage of round constants to eliminate symmetries., Diffusion of cipher key differences into the round keys; that is, each key bit, affects many round key bits., Enough nonlinearity to prohibit the full determination of round key differences from cipher key differences only., Simplicity of description.
Page 197 :
196, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, Table 6.5 Avalanche Effect in AES: Change in Plaintext, Number of Bits, that Differ, , Round, , 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, , 0123456789abcdeffedcba9876543210, 0023456789abcdeffedcba9876543210, 0e3634aece7225b6f26b174ed92b5588, 0f3634aece7225b6f26b174ed92b5588, 657470750fc7ff3fc0e8e8ca4dd02a9c, c4a9ad090fc7ff3fc0e8e8ca4dd02a9c, 5c7bb49a6b72349b05a2317ff46d1294, fe2ae569f7ee8bb8c1f5a2bb37ef53d5, 7115262448dc747e5cdac7227da9bd9c, ec093dfb7c45343d689017507d485e62, f867aee8b437a5210c24c1974cffeabc, 43efdb697244df808e8d9364ee0ae6f5, 721eb200ba06206dcbd4bce704fa654e, 7b28a5d5ed643287e006c099bb375302, 0ad9d85689f9f77bc1c5f71185e5fb14, 3bc2d8b6798d8ac4fe36a1d891ac181a, db18a8ffa16d30d5f88b08d777ba4eaa, 9fb8b5452023c70280e5c4bb9e555a4b, f91b4fbfe934c9bf8f2f85812b084989, 20264e1126b219aef7feb3f9b2d6de40, cca104a13e678500ff59025f3bafaa34, b56a0341b2290ba7dfdfbddcd8578205, ff0b844a0853bf7c6934ab4364148fb9, 612b89398d0600cde116227ce72433f0, , 1, 1, 20, 58, 59, 61, 68, 64, 67, 65, 61, 58, , plaintext (or key) space to be searched. What is desired is the avalanche effect, in, which a small change in plaintext or key produces a large change in the ciphertext., Using the example from Table 6.4, Table 6.5 shows the result when the, eighth bit of the plaintext is changed. The second column of the table shows the, value of the State matrix at the end of each round for the two plaintexts. Note, that after just one round, 20 bits of the State vector differ. After two rounds,, close to half the bits differ. This magnitude of difference propagates through, the remaining rounds. A bit difference in approximately half the positions in the, most desirable outcome. Clearly, if almost all the bits are changed, this would be, logically equivalent to almost none of the bits being changed. Put another way, if, we select two plaintexts at random, we would expect the two plaintexts to differ, in about half of the bit positions and the two ciphertexts to also differ in about, half the positions., Table 6.6 shows the change in State matrix values when the same plaintext, is used and the two keys differ in the eighth bit. That is, for the second case, the, key is 0e1571c947d9e8590cb7add6af7f6798. Again, one round produces, a significant change, and the magnitude of change after all subsequent rounds, is roughly half the bits. Thus, based on this example, AES exhibits a very strong, avalanche effect.
Page 198 :
6.6 / AES IMPLEMENTATION, , 197, , Table 6.6 Avalanche Effect in AES: Change in Key, Number of Bits, that Differ, , Round, , 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, , 0123456789abcdeffedcba9876543210, 0123456789abcdeffedcba9876543210, 0e3634aece7225b6f26b174ed92b5588, 0f3634aece7225b6f26b174ed92b5588, 657470750fc7ff3fc0e8e8ca4dd02a9c, c5a9ad090ec7ff3fc1e8e8ca4cd02a9c, 5c7bb49a6b72349b05a2317ff46d1294, 90905fa9563356d15f3760f3b8259985, 7115262448dc747e5cdac7227da9bd9c, 18aeb7aa794b3b66629448d575c7cebf, f867aee8b437a5210c24c1974cffeabc, f81015f993c978a876ae017cb49e7eec, 721eb200ba06206dcbd4bce704fa654e, 5955c91b4e769f3cb4a94768e98d5267, 0ad9d85689f9f77bc1c5f71185e5fb14, dc60a24d137662181e45b8d3726b2920, db18a8ffa16d30d5f88b08d777ba4eaa, fe8343b8f88bef66cab7e977d005a03c, f91b4fbfe934c9bf8f2f85812b084989, da7dad581d1725c5b72fa0f9d9d1366a, cca104a13e678500ff59025f3bafaa34, 0ccb4c66bbfd912f4b511d72996345e0, ff0b844a0853bf7c6934ab4364148fb9, fc8923ee501a7d207ab670686839996b, , 0, 1, 22, 58, 67, 63, 81, 70, 74, 67, 59, 53, , Note that this avalanche effect is stronger than that for DES (Table 4.2),, which requires three rounds to reach a point at which approximately half the bits, are changed, both for a bit change in the plaintext and a bit change in the key., , 6.6 AES IMPLEMENTATION, Equivalent Inverse Cipher, As was mentioned, the AES decryption cipher is not identical to the encryption, cipher (Figure 6.3). That is, the sequence of transformations for decryption differs, from that for encryption, although the form of the key schedules for encryption, and decryption is the same. This has the disadvantage that two separate software, or firmware modules are needed for applications that require both encryption and, decryption. There is, however, an equivalent version of the decryption algorithm, that has the same structure as the encryption algorithm. The equivalent version has, the same sequence of transformations as the encryption algorithm (with transformations replaced by their inverses). To achieve this equivalence, a change in key, schedule is needed.
Page 200 :
6.6 / AES IMPLEMENTATION, , 199, , Ciphertext, Add round key, , w[40, 43], , Inverse shift rows, Inverse mix cols, Inverse mix cols, , Round 1, , Inverse sub bytes, , Add round key, , w[36, 39], , ), ), ), , Inverse shift rows, Inverse mix cols, , w[4, 7], , Add round key, Inverse sub bytes, , Expand key, , Inverse shift rows, , w[0, 3], , Add round key, , Key, , Plaintext, , Figure 6.10, , Round 10, , Inverse mix cols, , Round 9, , Inverse sub bytes, , Equivalent Inverse Cipher, , Implementation Aspects, The Rijndael proposal [DAEM99] provides some suggestions for efficient implementation on 8-bit processors, typical for current smart cards, and on 32-bit, processors, typical for PCs., 8-BIT PROCESSOR AES can be implemented very efficiently on an 8-bit processor. AddRoundKey is a bytewise XOR operation. ShiftRows is a simple byteshifting operation. SubBytes operates at the byte level and only requires a table, of 256 bytes., The transformation MixColumns requires matrix multiplication in the field, GF(28), which means that all operations are carried out on bytes. MixColumns only, requires multiplication by {02} and {03}, which, as we have seen, involved simple, shifts, conditional XORs, and XORs. This can be implemented in a more efficient, , Hiva-Network.Com
Page 202 :
6.6 / AES IMPLEMENTATION, , 201, , In the ShiftRows equation, the column indices are taken mod 4. We can, combine all of these expressions into a single equation:, e0, j, 02, e1, j, 01, D, T = D, e2, j, 01, e3, j, 03, , 03, 02, 01, 01, , 01, 03, 02, 01, , 01, S[a0, j], k0, j, 01, S[a1, j - 1], k, TD, T ⊕ D 1, j T, 03, S[a2, j - 2], k2, j, 02, S[a3, j - 3], k3, j, , 03, 01, 02, 02 #, 03, 01 #, = § D T S[a0, j] ¥ ⊕ § D T S[a1, j - 1] ¥ ⊕ § D T # S[a2, j - 2] ¥, 01, 02, 01, 01, 01, 03, 01, k0, j, 01 #, k, ⊕ § D T S[a3, j - 3] ¥ ⊕ D 1, j T, 03, k2, j, 02, k3, j, In the second equation, we are expressing the matrix multiplication as a linear combination of vectors. We define four 256-word (1024-byte) tables as follows., 02, 03, 01, 01, 01, 02, 03, 01, T0[x] = § D T # S[x] ¥ T1[x] = § D T # S[x] ¥ T2[x] = § D T # S[x] ¥ T3[x] = § D T # S[x] ¥, 01, 01, 02, 03, 03, 01, 01, 02, , Thus, each table takes as input a byte value and produces a column vector (a 32-bit, word) that is a function of the S-box entry for that byte value. These tables can be, calculated in advance., We can define a round function operating on a column in the following fashion., =, s0,, j, =, s1,, D = j T = T0[s0, j] ⊕ T1[s1, j - 1] ⊕ T2[s2, j - 2] ⊕ T3[s3, j - 3] ⊕, s2, j, =, s3,, j, , k0, j, k, D 1, j T, k2, j, k3, j, , As a result, an implementation based on the preceding equation requires only, four table lookups and four XORs per column per round, plus 4 Kbytes to store the, table. The developers of Rijndael believe that this compact, efficient implementation was probably one of the most important factors in the selection of Rijndael, for AES.
Page 203 :
202, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , 6.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, Advanced Encryption, Standard (AES), avalanche effect, field, , finite field, irreducible, polynomial, key expansion, , National Institute of Standards, and Technology (NIST), Rijndael, S-box, , Review Questions, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 6.10, 6.11, 6.12, 6.13, 6.14, , What was the original set of criteria used by NIST to evaluate candidate AES ciphers?, What was the final set of criteria used by NIST to evaluate candidate AES ciphers?, What is the difference between Rijndael and AES?, What is the purpose of the State array?, How is the S-box constructed?, Briefly describe SubBytes., Briefly describe ShiftRows., How many bytes in State are affected by ShiftRows?, Briefly describe MixColumns., Briefly describe AddRoundKey., Briefly describe the key expansion algorithm., What is the difference between SubBytes and SubWord?, What is the difference between ShiftRows and RotWord?, What is the difference between the AES decryption algorithm and the equivalent, inverse cipher?, , Problems, 6.1, , In the discussion of MixColumns and InvMixColumns, it was stated that, b(x) = a-1(x) mod(x4 + 1), , 6.2, 6.3, 6.4, , 6.5, , where a(x) = {03}x3 + {01}x2 + {01}x + {02} and b(x) = {0B}x3 + {0D}x2 + {09}x +, {0E.} Show that this is true., a. What is {0 2 }-1 in GF(28)?, b. Verify the entry for {0 2 } in the S-box., Show the first eight words of the key expansion for a 128-bit key of all ones., Given the plaintext {0F0E0D0C0B0A09080706050403020100} and the key, {02020202020202020202020202020202}:, a. Show the original contents of State, displayed as a 4 * 4 matrix., b. Show the value of State after initial AddRoundKey., c. Show the value of State after SubBytes., d. Show the value of State after ShiftRows., e. Show the value of State after MixColumns., Verify Equation (6.11) in Appendix 6A. That is, show that xi mod (x4 + 1) = xi mod 4.
Page 204 :
APPENDIX 6A / POLYNOMIALS WITH COEFFICIENTS IN GF(28), 6.6, , 6.7, 6.8, , 6.9, , 6.10, , 6.11, , Compare AES to DES. For each of the following elements of DES, indicate the comparable element in AES or explain why it is not needed in AES., a. XOR of subkey material with the input to the f function, b. XOR of the f function output with the left half of the block, c. f function, d. permutation P, e. swapping of halves of the block, In the subsection on implementation aspects, it is mentioned that the use of tables, helps thwart timing attacks. Suggest an alternative technique., In the subsection on implementation aspects, a single algebraic equation is developed, that describes the four stages of a typical round of the encryption algorithm. Provide, the equivalent equation for the tenth round., Compute the output of the MixColumns transformation for the following sequence, of input bytes “A1 B2 C3 D4.” Apply the InvMixColumns transformation to the obtained result to verify your calculations. Change the first byte of the input from “A1”, to “A3” perform the MixColumns transformation again for the new input, and determine how many bits have changed in the output., Note: You can perform all calculations by hand or write a program supporting these, computations. If you choose to write a program, it should be written entirely by you;, no use of libraries or public domain source code is allowed in this assignment., Use the key 1010 1001 1100 0011 to encrypt the plaintext “hi” as expressed in ASCII, as 0110 1000 0110 1001. The designers of S-AES got the ciphertext 0011 1110 1111, 1011. Do you?, Show that the matrix given here, with entries in GF(24), is the inverse of the matrix, used in the MixColumns step of S-AES., ¢, , 6.12, , 6.13, , 203, , x3 + 1, x, , x, ≤, x3 + 1, , Carefully write up a complete decryption of the ciphertext 0011 1110 1111 1011 using, the key 1010 1001 1100 0011 and the S-AES algorithm. You should get the plaintext, we started with in Problem 6.10. Note that the inverse of the S-boxes can be done, with a reverse table lookup. The inverse of the MixColumns step is given by the matrix in the previous problem., Demonstrate that Equation (6.9) is equivalent to Equation (6.4)., , Programming Problems, 6.14, , 6.15, , Create software that can encrypt and decrypt using S-AES. Test data: A binary, plaintext of 0110 1111 0110 1011 encrypted with a binary key of 1010 0111 0011 1011, should give a binary ciphertext of 0000 0111 0011 1000. Decryption should work, correspondingly., Implement a differential cryptanalysis attack on 1-round S-AES., , APPENDIX 6A, , POLYNOMIALS WITH COEFFICIENTS IN GF(28), , In Section 5.5, we discussed polynomial arithmetic in which the coefficients are in Z p, and the polynomials are defined modulo a polynomial m(x) whose highest power, is some integer n. In this case, addition and multiplication of coefficients occurred, within the field Z p; that is, addition and multiplication were performed modulo p.
Page 205 :
204, , CHAPTER 6 / ADVANCED ENCRYPTION STANDARD, , The AES document defines polynomial arithmetic for polynomials of degree 3, or less with coefficients in GF(28). The following rules apply., 1. Addition is performed by adding corresponding coefficients in GF(28). As was, pointed out Section 5.4, if we treat the elements of GF(28) as 8-bit strings, then, addition is equivalent to the XOR operation. So, if we have, a(x) = a3x3 + a2x2 + a1x + a0, , (6.10), , b(x) = b3x3 + b2x2 + b1x + b0, , (6.11), , and, , then, a(x) + b(x) = (a3 ⊕ b3)x3 + (a2 ⊕ b2)x2 + (a1 ⊕ b1)x + (a0 ⊕ b0), 2. Multiplication is performed as in ordinary polynomial multiplication with two, refinements:, a. Coefficients are multiplied in GF(28)., b. The resulting polynomial is reduced mod (x4 + 1)., We need to keep straight which polynomial we are talking about. Recall from, Section 5.6 that each element of GF(28) is a polynomial of degree 7 or less with binary coefficients, and multiplication is carried out modulo a polynomial of degree, 8. Equivalently, each element of GF(28) can be viewed as an 8-bit byte whose bit, values correspond to the binary coefficients of the corresponding polynomial. For, the sets defined in this section, we are defining a polynomial ring in which each element of this ring is a polynomial of degree 3 or less with coefficients in GF(28), and, multiplication is carried out modulo a polynomial of degree 4. Equivalently, each, element of this ring can be viewed as a 4-byte word whose byte values are elements, of GF(28) that correspond to the 8-bit coefficients of the corresponding polynomial., We denote the modular product of a(x) and b(x) by a(x) ⊕ b(x). To compute d(x) = a(x) ⊕ b(x), the first step is to perform a multiplication without the, modulo operation and to collect coefficients of like powers. Let us express this as, c(x) = a(x) * b(x). Then, c(x) = c6x6 + c5x5 + c4x4 + c3x3 + c2x2 + c1x + c0, , (6.12), , where, c0, c1, c2, c3, , =, =, =, =, , a0 # b0, (a1 # b0) ⊕ (a0 # b1), (a2 # b0) ⊕ (a1 # b1) ⊕ (a0 # b2), (a3 # b0) ⊕ (a2 # b1) ⊕ (a1 # b2) ⊕ (a0 # b3), , c4 = (a3 # b1) ⊕ (a2 # b2) ⊕ (a1 # b3), c5 = (a3 # b2) ⊕ (a2 # b3), c6 = a3 # b3, , The final step is to perform the modulo operation, d(x) = c(x) mod (x4 + 1)
Page 208 :
CHAPTER, , Block Cipher Operation, 7.1, , Multiple Encryption and Triple DES, Double DES, Triple DES with Two Keys, Triple DES with Three Keys, , 7.2, , Electronic Codebook, , 7.3, , Cipher Block Chaining Mode, , 7.4, , Cipher Feedback Mode, , 7.5, , Output Feedback Mode, , 7.6, , Counter Mode, , 7.7, , XTS-AES Mode for Block-Oriented Storage Devices, Tweakable Block Ciphers, Storage Encryption Requirements, Operation on a Single Block, Operation on a Sector, , 7.8, , Format-Preserving Encryption, Motivation, Difficulties in Designing an FPE, Feistel Structure for Format-Preserving Encryption, NIST Methods for Format-Preserving Encryption, , 7.9, , Key Terms, Review Questions, and Problems, , 207
Page 209 :
208, , CHAPTER 7 / BLOCK CIPHER OPERATION, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, , Analyze the security of multiple encryption schemes., Explain the meet-in-the-middle attack., Compare and contrast ECB, CBC, CFB, OFB, and counter modes of operation., Present an overview of the XTS-AES mode of operation., , This chapter continues our discussion of symmetric ciphers. We begin with the topic of, multiple encryption, looking in particular at the most widely used multiple-encryption, scheme: triple DES., The chapter next turns to the subject of block cipher modes of operation. We, find that there are a number of different ways to apply a block cipher to plaintext, each, with its own advantages and particular applications., , 7.1 MULTIPLE ENCRYPTION AND TRIPLE DES, Because of its vulnerability to brute-force attack, DES, once the most widely used, symmetric cipher, has been largely replaced by stronger encryption schemes. Two, approaches have been taken. One approach is to design a completely new algorithm that is resistant to both cryptanalytic and brute-force attacks, of which AES, is a prime example. Another alternative, which preserves the existing investment in, software and equipment, is to use multiple encryption with DES and multiple keys., We begin by examining the simplest example of this second alternative. We then, look at the widely accepted triple DES (3DES) algorithm., , Double DES, The simplest form of multiple encryption has two encryption stages and two keys, (Figure 7.1a). Given a plaintext P and two encryption keys K1 and K2, ciphertext C, is generated as, C = E(K2, E(K1, P)), Decryption requires that the keys be applied in reverse order:, P = D(K1, D(K2, C)), For DES, this scheme apparently involves a key length of 56 * 2 = 112 bits, and, should result in a dramatic increase in cryptographic strength. But we need to examine the algorithm more closely., , Hiva-Network.Com
Page 210 :
7.1 / MULTIPLE ENCRYPTION AND TRIPLE DES, K1, , K2, , X, , E, , P, , 209, , E, , C, , Encryption, K1, , K2, , X, , D, , C, , D, , P, , Decryption, , (a) Double encryption, , K2, , K1, , P, , E, , K3, or, K1, , A, , B, , D, , (3-key), (2-key), , E, , C, , Encryption, , K1, , C, , D, , K3, or, K1, , K2, , B, , E, , A, , D, , (3-key), (2-key), , P, , Decryption, , (b) Triple encryption, Figure 7.1, , Multiple Encryption, , REDUCTION TO A SINGLE STAGE Suppose it were true for DES, for all 56-bit key values, that given any two keys K1 and K2, it would be possible to find a key K3 such that, E(K2, E(K1, P)) = E(K3, P), , (7.1), , If this were the case, then double encryption, and indeed any number of stages of, multiple encryption with DES, would be useless because the result would be equivalent to a single encryption with a single 56-bit key., On the face of it, it does not appear that Equation (7.1) is likely to hold., Consider that encryption with DES is a mapping of 64-bit blocks to 64-bit blocks., In fact, the mapping can be viewed as a permutation. That is, if we consider all 264, possible input blocks, DES encryption with a specific key will map each block into a, unique 64-bit block. Otherwise, if, say, two given input blocks mapped to the same, output block, then decryption to recover the original plaintext would be impossible.
Page 211 :
210, , CHAPTER 7 / BLOCK CIPHER OPERATION, , With 264 possible inputs, how many different mappings are there that generate a, permutation of the input blocks? The value is easily seen to be, 20, , (264)! = 10347380000000000000000 7 (1010 ), On the other hand, DES defines one mapping for each different key, for a total, number of mappings:, 256 6 1017, Therefore, it is reasonable to assume that if DES is used twice with different keys, it, will produce one of the many mappings that are not defined by a single application, of DES. Although there was much supporting evidence for this assumption, it was, not until 1992 that the assumption was proven [CAMP92]., MEET-IN-THE-MIDDLE ATTACK Thus, the use of double DES results in a mapping, that is not equivalent to a single DES encryption. But there is a way to attack this, scheme, one that does not depend on any particular property of DES but that will, work against any block encryption cipher., The algorithm, known as a meet-in-the-middle attack, was first described in, [DIFF77]. It is based on the observation that, if we have, C = E(K2, E(K1, P)), then (see Figure 7.1a), X = E(K1, P) = D(K2, C), Given a known pair, (P, C), the attack proceeds as follows. First, encrypt P for all, 256 possible values of K1. Store these results in a table and then sort the table by the, values of X. Next, decrypt C using all 256 possible values of K2. As each decryption, is produced, check the result against the table for a match. If a match occurs, then, test the two resulting keys against a new known plaintext–ciphertext pair. If the two, keys produce the correct ciphertext, accept them as the correct keys., For any given plaintext P, there are 264 possible ciphertext values that could be, produced by double DES. Double DES uses, in effect, a 112-bit key, so that there, are 2112 possible keys. Therefore, for a given plaintext P, the maximum number, of different 112-bit keys that could produce a given ciphertext C is 2112/264 = 248., Thus, the foregoing procedure can produce about 248 false alarms on the first (P, C), pair. A similar argument indicates that with an additional 64 bits of known plaintext, and ciphertext, the false alarm rate is reduced to 248 - 64 = 2-16. Put another way,, if the meet-in-the-middle attack is performed on two blocks of known plaintext–, ciphertext, the probability that the correct keys are determined is 1 - 2-16. The, result is that a known plaintext attack will succeed against double DES, which has a, key size of 112 bits, with an effort on the order of 256, which is not much more than, the 255 required for single DES., , Triple DES with Two Keys, An obvious counter to the meet-in-the-middle attack is to use three stages of, encryption with three different keys. Using DES as the underlying algorithm,, this approach is commonly referred to as 3DES, or Triple Data Encryption
Page 212 :
7.1 / MULTIPLE ENCRYPTION AND TRIPLE DES, , 211, , Algorithm (TDEA). As shown in Figure 7.1b, there are two versions of 3DES;, one using two keys and one using three keys. NIST SP 800-67 (Recommendation, for the Triple Data Encryption Block Cipher, January 2012) defines the two-key, and three-key versions. We look first at the strength of the two-key version and, then examine the three-key version., Two-key triple encryption was first proposed by Tuchman [TUCH79]. The, function follows an encrypt-decrypt-encrypt (EDE) sequence (Figure 7.1b):, C = E(K1, D(K2, E(K1, P))), P = D(K1, E(K2, D(K1, C))), There is no cryptographic significance to the use of decryption for the second, stage. Its only advantage is that it allows users of 3DES to decrypt data encrypted by, users of the older single DES:, C = E(K1, D(K1, E(K1, P))) = E(K1, P), P = D(K1, E(K1, D(K1, C))) = D(K1, C), 3DES with two keys is a relatively popular alternative to DES and has been, adopted for use in the key management standards ANSI X9.17 and ISO 8732.1, Currently, there are no practical cryptanalytic attacks on 3DES. Coppersmith, [COPP94] notes that the cost of a brute-force key search on 3DES is on the order of, 2112 ≈ (5 * 1033) and estimates that the cost of differential cryptanalysis suffers an, exponential growth, compared to single DES, exceeding 1052., It is worth looking at several proposed attacks on 3DES that, although not, practical, give a flavor for the types of attacks that have been considered and that, could form the basis for more successful future attacks., The first serious proposal came from Merkle and Hellman [MERK81]. Their, plan involves finding plaintext values that produce a first intermediate value of, A = 0 (Figure 7.1b) and then using the meet-in-the-middle attack to determine, the two keys. The level of effort is 256, but the technique requires 256 chosen plaintext–ciphertext pairs, which is a number unlikely to be provided by the holder of, the keys., A known-plaintext attack is outlined in [VANO90]. This method is an improvement over the chosen-plaintext approach but requires more effort. The attack, is based on the observation that if we know A and C (Figure 7.1b), then the problem, reduces to that of an attack on double DES. Of course, the attacker does not know, A, even if P and C are known, as long as the two keys are unknown. However, the, attacker can choose a potential value of A and then try to find a known (P, C) pair, that produces A. The attack proceeds as follows., 1. Obtain n (P, C) pairs. This is the known plaintext. Place these in a table, (Table 1) sorted on the values of P (Figure 7.2b)., 1, , American National Standards Institute (ANSI): Financial Institution Key Management (Wholesale)., From its title, X9.17 appears to be a somewhat obscure standard. Yet a number of techniques specified in, this standard have been adopted for use in other standards and applications, as we shall see throughout, this book.
Page 213 :
212, , CHAPTER 7 / BLOCK CIPHER OPERATION, j, , i, , Pi, , a, , E, , D, , i, , Bj, , E, , Ci, , (a) Two-key triple encryption with candidate pair of keys, Pi, , Ci, , Bj, , (b) Table of n known, plaintext–ciphertext, pairs, sorted on P, Figure 7.2, , Key i, , (c) Table of intermediate, values and candidate, keys, , Known-Plaintext Attack on Triple DES, , 2. Pick an arbitrary value a for A, and create a second table (Figure 7.2c) with entries defined in the following fashion. For each of the 256 possible keys K1 = i,, calculate the plaintext value Pi such that, Pi = D(i, a), For each Pi that matches an entry in Table 1, create an entry in Table 2 consisting of the K1 value and the value of B that is produced for the (P, C) pair from, Table 1, assuming that value of K1:, B = D(i, C), At the end of this step, sort Table 2 on the values of B., 3. We now have a number of candidate values of K1 in Table 2 and are in a, position to search for a value of K2. For each of the 256 possible keys K2 = j,, calculate the second intermediate value for our chosen value of a:, Bj = D(j, a), At each step, look up Bj in Table 2. If there is a match, then the corresponding, key i from Table 2 plus this value of j are candidate values for the unknown, keys (K1, K2). Why? Because we have found a pair of keys (i, j) that produce a, known (P, C) pair (Figure 7.2a)., 4. Test each candidate pair of keys (i, j) on a few other plaintext–ciphertext pairs., If a pair of keys produces the desired ciphertext, the task is complete. If no pair, succeeds, repeat from step 1 with a new value of a.
Page 214 :
7.2 / ELECTRONIC CODEBOOK, , 213, , For a given known (P, C), the probability of selecting the unique value of a, that leads to success is 1/264. Thus, given n (P, C) pairs, the probability of success for, a single selected value of a is n/264. A basic result from probability theory is that the, expected number of draws required to draw one red ball out of a bin containing n, red balls and N - n green balls is (N + 1)/(n + 1) if the balls are not replaced. So, the expected number of values of a that must be tried is, for large n,, 264, 264 + 1, ≈, n, n + 1, Thus, the expected running time of the attack is on the order of, (256), , 264, = 2120 - log2 n, n, , Triple DES with Three Keys, Although the attacks just described appear impractical, anyone using two-key 3DES, may feel some concern. Thus, many researchers now feel that three-key 3DES is the, preferred alternative (e.g., [KALI96a]). In SP 800-57, Part 1 (Recommendation for, Key Management—Part 1: General, July 2012) NIST recommends that 2-key 3DES, be retired as soon as practical and replaced with 3-key 3DES., Three-key 3DES is defined as, C = E(K3, D(K2, E(K1, P))), Backward compatibility with DES is provided by putting K3 = K2 or K1 = K2. One, might expect that 3TDEA would provide 56 # 3 = 168 bits of strength. However,, there is an attack on 3TDEA that reduces the strength to the work that would be, involved in exhausting a 112-bit key [MERK81]., A number of Internet-based applications have adopted three-key 3DES, including PGP and S/MIME, both discussed in Chapter 19., , 7.2 ELECTRONIC CODEBOOK, A block cipher takes a fixed-length block of text of length b bits and a key as input, and produces a b-bit block of ciphertext. If the amount of plaintext to be encrypted, is greater than b bits, then the block cipher can still be used by breaking the plaintext up into b-bit blocks. When multiple blocks of plaintext are encrypted using the, same key, a number of security issues arise. To apply a block cipher in a variety of, applications, five modes of operation have been defined by NIST (SP 800-38A)., In essence, a mode of operation is a technique for enhancing the effect of a cryptographic algorithm or adapting the algorithm for an application, such as applying, a block cipher to a sequence of data blocks or a data stream. The five modes are, intended to cover a wide variety of applications of encryption for which a block, cipher could be used. These modes are intended for use with any symmetric block, cipher, including triple DES and AES. The modes are summarized in Table 7.1 and, described in this and the following sections.
Page 215 :
214, , CHAPTER 7 / BLOCK CIPHER OPERATION, Table 7.1, , Block Cipher Modes of Operation, Mode, , Description, , Typical Application, , Electronic Codebook (ECB), , Each block of plaintext bits is, encoded independently using the, same key., , r Secure transmission of, single values (e.g., an, encryption key), , Cipher Block Chaining (CBC), , The input to the encryption algorithm is the XOR of the next block, of plaintext and the preceding, block of ciphertext., , r General-purpose blockoriented transmission, r Authentication, , Cipher Feedback (CFB), , Input is processed s bits at a time., Preceding ciphertext is used as, input to the encryption algorithm, to produce pseudorandom output,, which is XORed with plaintext to, produce next unit of ciphertext., , r General-purpose, stream-oriented, transmission, r Authentication, , Output Feedback (OFB), , Similar to CFB, except that the, input to the encryption algorithm, is the preceding encryption output,, and full blocks are used., , r Stream-oriented, transmission over noisy, channel (e.g., satellite, communication), , Counter (CTR), , Each block of plaintext is XORed, with an encrypted counter. The, counter is incremented for each, subsequent block., , r General-purpose blockoriented transmission, r Useful for high-speed, requirements, , The simplest mode is the electronic codebook (ECB) mode, in which plaintext, is handled one block at a time and each block of plaintext is encrypted using the, same key (Figure 7.3). The term codebook is used because, for a given key, there is, a unique ciphertext for every b-bit block of plaintext. Therefore, we can imagine a, gigantic codebook in which there is an entry for every possible b-bit plaintext pattern showing its corresponding ciphertext., For a message longer than b bits, the procedure is simply to break the message, into b-bit blocks, padding the last block if necessary. Decryption is performed one, block at a time, always using the same key. In Figure 7.3, the plaintext (padded as, necessary) consists of a sequence of b-bit blocks, P1, P2, c , PN; the corresponding sequence of ciphertext blocks is C1, C2, c , CN. We can define ECB mode as, follows., ECB, , C j = E(K, Pj), , j = 1, c , N, , Pj = D(K, Cj), , j = 1, c , N, , The ECB mode should be used only to secure messages shorter than a single, block of underlying cipher (i.e., 64 bits for 3DES and 128 bits for AES), such as to, encrypt a secret key. Because in most of the cases messages are longer than the encryption block mode, this mode has a minimum practical value., The most significant characteristic of ECB is that if the same b-bit block of, plaintext appears more than once in the message, it always produces the same, ciphertext.
Page 216 :
7.2 / ELECTRONIC CODEBOOK, P1, , P2, , K, , K, , 215, , PN, , K, , Encrypt, , Encrypt, , Encrypt, , C1, , C2, , CN, , (a) Encryption, , C1, , C2, , K, , K, , CN, , K, , Decrypt, , Decrypt, , Decrypt, , P1, , P2, , PN, , (b) Decryption, Figure 7.3, , Electronic Codebook (ECB) Mode, , For lengthy messages, the ECB mode may not be secure. If the message is, highly structured, it may be possible for a cryptanalyst to exploit these regularities., For example, if it is known that the message always starts out with certain predefined, fields, then the cryptanalyst may have a number of known plaintext–ciphertext pairs, to work with. If the message has repetitive elements with a period of repetition a, multiple of b bits, then these elements can be identified by the analyst. This may help, in the analysis or may provide an opportunity for substituting or rearranging blocks., We now turn to more complex modes of operation. [KNUD00] lists the following criteria and properties for evaluating and constructing block cipher modes of, operation that are superior to ECB:, ■, ■, ■, , Overhead: The additional operations for the encryption and decryption operation when compared to encrypting and decrypting in the ECB mode., Error recovery: The property that an error in the ith ciphertext block is inherited by only a few plaintext blocks after which the mode resynchronizes., Error propagation: The property that an error in the ith ciphertext block is, inherited by the ith and all subsequent plaintext blocks. What is meant here is, a bit error that occurs in the transmission of a ciphertext block, not a computational error in the encryption of a plaintext block.
Page 217 :
216, , CHAPTER 7 / BLOCK CIPHER OPERATION, ■, , ■, , Diffusion: How the plaintext statistics are reflected in the ciphertext. Low entropy plaintext blocks should not be reflected in the ciphertext blocks. Roughly,, low entropy equates to predictability or lack of randomness (see Appendix F)., Security: Whether or not the ciphertext blocks leak information about the, plaintext blocks., , 7.3 CIPHER BLOCK CHAINING MODE, To overcome the security deficiencies of ECB, we would like a technique in which, the same plaintext block, if repeated, produces different ciphertext blocks. A, simple way to satisfy this requirement is the cipher block chaining (CBC) mode, (Figure 7.4). In this scheme, the input to the encryption algorithm is the XOR of the, current plaintext block and the preceding ciphertext block; the same key is used for, each block. In effect, we have chained together the processing of the sequence of, plaintext blocks. The input to the encryption function for each plaintext block bears, no fixed relationship to the plaintext block. Therefore, repeating patterns of b bits, are not exposed. As with the ECB mode, the CBC mode requires that the last block, be padded to a full b bits if it is a partial block., P1, , IV, , P2, , PN, CN–1, , K, , K, , K, , Encrypt, , Encrypt, , Encrypt, , C1, , C2, , CN, , (a) Encryption, , C1, , C2, , K, , K, Decrypt, , CN, , K, Decrypt, , Decrypt, , IV, CN–1, , P1, , P2, , (b) Decryption, Figure 7.4, , Cipher Block Chaining (CBC) Mode, , PN
Page 218 :
7.3 / CIPHER BLOCK CHAINING MODE, , 217, , For decryption, each cipher block is passed through the decryption algorithm., The result is XORed with the preceding ciphertext block to produce the plaintext, block. To see that this works, we can write, Cj = E(K, [Cj - 1 ⊕ Pj]), Then, D(K, Cj) = D(K, E(K, [Cj - 1 ⊕ Pj])), D(K, Cj) = Cj - 1 ⊕ Pj, Cj - 1 ⊕ D(K, Cj) = Cj - 1 ⊕ Cj - 1 ⊕ Pj = Pj, To produce the first block of ciphertext, an initialization vector (IV) is XORed, with the first block of plaintext. On decryption, the IV is XORed with the output, of the decryption algorithm to recover the first block of plaintext. The IV is a data, block that is the same size as the cipher block. We can define CBC mode as, CBC, , C1 = E(K, [P1 ⊕ IV]), , P1 = D(K, C1) ⊕ IV, , Cj = E(K, [Pj ⊕ Cj - 1])j = 2, c , N, , Pj = D(K, Cj) ⊕ Cj - 1 j = 2, c , N, , The IV must be known to both the sender and receiver but be unpredictable, by a third party. In particular, for any given plaintext, it must not be possible to, predict the IV that will be associated to the plaintext in advance of the generation, of the IV. For maximum security, the IV should be protected against unauthorized, changes. This could be done by sending the IV using ECB encryption. One reason, for protecting the IV is as follows: If an opponent is able to fool the receiver into, using a different value for IV, then the opponent is able to invert selected bits in the, first block of plaintext. To see this, consider, C1 = E(K, [IV ⊕ P1]), P1 = IV ⊕ D(K, C1), Now use the notation that X[i] denotes the ith bit of the b-bit quantity X. Then, P1[i] = IV[i] ⊕ D(K, C1)[i], Then, using the properties of XOR, we can state, P1[i]′ = IV[i]′ ⊕ D(K, C1)[i], where the prime notation denotes bit complementation. This means that if an opponent can predictably change bits in IV, the corresponding bits of the received value, of P1 can be changed., For other possible attacks based on prior knowledge of IV, see [VOYD83]., So long as it is unpredictable, the specific choice of IV is unimportant., SP 800-38A recommends two possible methods: The first method is to apply, the encryption function, under the same key that is used for the encryption of the, plaintext, to a nonce.2 The nonce must be a data block that is unique to each, 2, NIST SP 800-90 (Recommendation for Random Number Generation Using Deterministic Random Bit, Generators) defines nonce as follows: A time-varying value that has at most a negligible chance of repeating, for example, a random value that is generated anew for each use, a timestamp, a sequence number,, or some combination of these., , Hiva-Network.Com
Page 219 :
218, , CHAPTER 7 / BLOCK CIPHER OPERATION, , execution of the encryption operation. For example, the nonce may be a counter,, a timestamp, or a message number. The second method is to generate a random, data block using a random number generator., In conclusion, because of the chaining mechanism of CBC, it is an appropriate, mode for encrypting messages of length greater than b bits., In addition to its use to achieve confidentiality, the CBC mode can be used for, authentication. This use is described in Chapter 12., , 7.4 CIPHER FEEDBACK MODE, For AES, DES, or any block cipher, encryption is performed on a block of b bits., In the case of DES, b = 64 and in the case of AES, b = 128. However, it is possible to convert a block cipher into a stream cipher, using one of the three modes, to be discussed in this and the next two sections: cipher feedback (CFB) mode,, output feedback (OFB) mode, and counter (CTR) mode. A stream cipher eliminates the need to pad a message to be an integral number of blocks. It also can, operate in real time. Thus, if a character stream is being transmitted, each character can be encrypted and transmitted immediately using a character-oriented, stream cipher., One desirable property of a stream cipher is that the ciphertext be of the same, length as the plaintext. Thus, if 8-bit characters are being transmitted, each character should be encrypted to produce a ciphertext output of 8 bits. If more than 8 bits, are produced, transmission capacity is wasted., Figure 7.5 depicts the CFB scheme. In the figure, it is assumed that the unit of, transmission is s bits; a common value is s = 8. As with CBC, the units of plaintext, are chained together, so that the ciphertext of any plaintext unit is a function of all, the preceding plaintext. In this case, rather than blocks of b bits, the plaintext is, divided into segments of s bits., First, consider encryption. The input to the encryption function is a b-bit shift, register that is initially set to some initialization vector (IV). The leftmost (most, significant) s bits of the output of the encryption function are XORed with the first, segment of plaintext P1 to produce the first unit of ciphertext C1, which is then, transmitted. In addition, the contents of the shift register are shifted left by s bits,, and C1 is placed in the rightmost (least significant) s bits of the shift register. This, process continues until all plaintext units have been encrypted., For decryption, the same scheme is used, except that the received ciphertext, unit is XORed with the output of the encryption function to produce the plaintext, unit. Note that it is the encryption function that is used, not the decryption function., This is easily explained. Let MSB s(X) be defined as the most significant s bits of X., Then, C1 = P1 ⊕ MSB s[E(K, IV)], Therefore, by rearranging terms:, P1 = C1 ⊕ MSB s[E(K, IV)], The same reasoning holds for subsequent steps in the process.
Page 220 :
7.4 / CIPHER FEEDBACK MODE, , 219, , CN–1, , Shift register, , IV, , b – s bits, , I1, , K, , Shift register, , s bits, , b – s bits, , I2, , K, , Encrypt, , Encrypt, , O1, , Encrypt, , O2, , Select Discard, s bits b – s bits, , ON, , Select Discard, s bits b – s bits, , s bits, P1, , s bits, , IN, , K, , Select Discard, s bits b – s bits, , s bits, P2, , s bits, PN, , C1, , C2, , CN, , s bits, , s bits, , s bits, , (a) Encryption, CN–1, , Shift register, , IV, , b – s bits, , I1, , K, , b – s bits, , I2, , K, , Encrypt, , Shift register, , s bits, , Encrypt, , O1, , Encrypt, ON, , O2, , Select Discard, s bits b – s bits, , s bits, , IN, , K, , Select Discard, s bits b – s bits, , Select Discard, s bits b – s bits, , C1, , C2, , CN, , s bits, , s bits, , s bits, , P1, , P2, , PN, , s bits, , s bits, , s bits, , (b) Decryption, Figure 7.5 s-bit Cipher Feedback (CFB) Mode, , We can define CFB mode as follows., I1 = IV, CFB, , Ij = LSB b - s(Ij - 1) } Cj - 1, , I1 = IV, j = 2, c, N, , Ij = LSB b - s(Ij - 1) }Cj - 1 j = 2, c, N, , Oj = E(K, Ij), , j = 1, c, N, , Oj = E(K, Ij), , j = 1, c, N, , Cj = Pj ⊕ MSB s(Oj), , j = 1, c, N, , Pj = Cj ⊕ MSB s(Oj), , j = 1, c, N, , Although CFB can be viewed as a stream cipher, it does not conform to the, typical construction of a stream cipher. In a typical stream cipher, the cipher takes
Page 221 :
220, , CHAPTER 7 / BLOCK CIPHER OPERATION, , as input some initial value and a key and generates a stream of bits, which is then, XORed with the plaintext bits (see Figure 4.1). In the case of CFB, the stream of, bits that is XORed with the plaintext also depends on the plaintext., In CFB encryption, like CBC encryption, the input block to each forward, cipher function (except the first) depends on the result of the previous forward, cipher function; therefore, multiple forward cipher operations cannot be performed, in parallel. In CFB decryption, the required forward cipher operations can be performed in parallel if the input blocks are first constructed (in series) from the IV, and the ciphertext., , 7.5 OUTPUT FEEDBACK MODE, The output feedback (OFB) mode is similar in structure to that of CFB. For OFB,, the output of the encryption function is fed back to become the input for encrypting, the next block of plaintext (Figure 7.6). In CFB, the output of the XOR unit is fed, back to become input for encrypting the next block. The other difference is that the, OFB mode operates on full blocks of plaintext and ciphertext, whereas CFB operates on an s-bit subset. OFB encryption can be expressed as, Cj = Pj ⊕ E(K, Oj - 1), where, Oj - 1 = E(K, Oj - 2), Some thought should convince you that we can rewrite the encryption expression as:, Cj = Pj ⊕ E(K, [Cj - 1 ⊕ Pj - 1]), By rearranging terms, we can demonstrate that decryption works., Pj = Cj ⊕ E(K, [Cj - 1 ⊕ Pj - 1]), We can define OFB mode as follows., I1 = Nonce, Ij = Oj - 1, OFB, , I1 = Nonce, j = 2, c , N, , Oj = E(K, Ij), , j = 1, c , N, , Cj = Pj ⊕ Oj, , j = 1, c , N - 1, , * = P* ⊕ MSB (O ), CN, N, u, N, , Ij = Oj - 1, , j = 2, c , N, , Oj = E(K, Ij), , j = 1, c , N, , Pj = Cj ⊕ Oj, , j = 1, c , N - 1, , * = C * ⊕ MSB (O ), PN, N, u, N, , Let the size of a block be b. If the last block of plaintext contains u bits (indicated by *), with u 6 b, the most significant u bits of the last output block ON are, used for the XOR operation; the remaining b - u bits of the last output block are, discarded., As with CBC and CFB, the OFB mode requires an initialization vector. In, the case of OFB, the IV must be a nonce; that is, the IV must be unique to each, execution of the encryption operation. The reason for this is that the sequence of
Page 222 :
7.5 / OUTPUT FEEDBACK MODE, , 221, , Nonce, I1, , K, , I2, , K, , Encrypt, , Encrypt, , O1, , P1, , IN, , K, , Encrypt, , O2, , P2, , C1, , PN, , C2, , ON, , CN, , (a) Encryption, , Nonce, I1, , K, , I2, , K, , Encrypt, , O1, , C1, , IN, , K, , Encrypt, , O2, , C2, , P1, , P2, , Encrypt, , CN, , ON, , PN, , (b) Decryption, Figure 7.6, , Output Feedback (OFB) Mode, , encryption output blocks, Oi, depends only on the key and the IV and does not depend on the plaintext. Therefore, for a given key and IV, the stream of output bits, used to XOR with the stream of plaintext bits is fixed. If two different messages had, an identical block of plaintext in the identical position, then an attacker would be, able to determine that portion of the Oi stream., One advantage of the OFB method is that bit errors in transmission do not, propagate. For example, if a bit error occurs in C1, only the recovered value of P1 is, affected; subsequent plaintext units are not corrupted. With CFB, C1 also serves as, input to the shift register and therefore causes additional corruption downstream., The disadvantage of OFB is that it is more vulnerable to a message stream, modification attack than is CFB. Consider that complementing a bit in the ciphertext complements the corresponding bit in the recovered plaintext. Thus, controlled
Page 223 :
222, , CHAPTER 7 / BLOCK CIPHER OPERATION, , changes to the recovered plaintext can be made. This may make it possible for an, opponent, by making the necessary changes to the checksum portion of the message, as well as to the data portion, to alter the ciphertext in such a way that it is not detected by an error-correcting code. For a further discussion, see [VOYD83]., OFB has the structure of a typical stream cipher, because the cipher generates a stream of bits as a function of an initial value and a key, and that stream of, bits is XORed with the plaintext bits (see Figure 4.1). The generated stream that is, XORed with the plaintext is itself independent of the plaintext; this is highlighted, by dashed boxes in Figure 7.6. One distinction from the stream ciphers we discuss, in Chapter 8 is that OFB encrypts plaintext a full block at a time, where typically a, block is 64 or 128 bits. Many stream ciphers encrypt one byte at a time., , 7.6 COUNTER MODE, Although interest in the counter (CTR) mode has increased recently with applications to ATM (asynchronous transfer mode) network security and IPsec, (IP security), this mode was proposed in 1979 (e.g., [DIFF79])., Figure 7.7 depicts the CTR mode. A counter equal to the plaintext block size, is used. The only requirement stated in SP 800-38A is that the counter value must be, different for each plaintext block that is encrypted. Typically, the counter is initialized to some value and then incremented by 1 for each subsequent block (modulo 2b,, where b is the block size). For encryption, the counter is encrypted and then XORed, with the plaintext block to produce the ciphertext block; there is no chaining. For, decryption, the same sequence of counter values is used, with each encrypted counter XORed with a ciphertext block to recover the corresponding plaintext block., Thus, the initial counter value must be made available for decryption. Given a, sequence of counters T1, T2, c , TN, we can define CTR mode as follows., , CTR, , Cj = Pj ⊕ E(K, Tj), , j = 1, c , N - 1, , * = P* ⊕ MSB [E(K, T )], CN, N, u, N, , Pj = Cj ⊕ E(K, Tj), , j = 1, c , N - 1, , * = C * ⊕ MSB [E(K, T )], PN, N, u, N, , For the last plaintext block, which may be a partial block of u bits, the most, significant u bits of the last output block are used for the XOR operation; the remaining b - u bits are discarded. Unlike the ECB, CBC, and CFB modes, we do, not need to use padding because of the structure of the CTR mode., As with the OFB mode, the initial counter value must be a nonce; that is, T1, must be different for all of the messages encrypted using the same key. Further,, all Ti values across all messages must be unique. If, contrary to this requirement, a, counter value is used multiple times, then the confidentiality of all of the plaintext, blocks corresponding to that counter value may be compromised. In particular, if, any plaintext block that is encrypted using a given counter value is known, then, the output of the encryption function can be determined easily from the associated, ciphertext block. This output allows any other plaintext blocks that are encrypted, using the same counter value to be easily recovered from their associated ciphertext, blocks.
Page 224 :
7.6 / COUNTER MODE, , K, , Counter N, , Counter 2, , Counter 1, K, , K, , Encrypt, , Encrypt, , P1, , 223, , Encrypt, , P2, , C1, , PN, , C2, , CN, , (a) Encryption, , Counter 1, K, , Counter N, , Counter 2, K, , K, , Encrypt, , C1, , Encrypt, , C2, , P1, , Encrypt, , CN, , P2, , PN, , (b) Decryption, Figure 7.7 Counter (CTR) Mode, , One way to ensure the uniqueness of counter values is to continue to increment the counter value by 1 across messages. That is, the first counter value of the, each message is one more than the last counter value of the preceding message., [LIPM00] lists the following advantages of CTR mode., ■, , Hardware efficiency: Unlike the three chaining modes, encryption (or decryption) in CTR mode can be done in parallel on multiple blocks of plaintext or, ciphertext. For the chaining modes, the algorithm must complete the computation on one block before beginning on the next block. This limits the maximum, throughput of the algorithm to the reciprocal of the time for one execution of, block encryption or decryption. In CTR mode, the throughput is only limited, by the amount of parallelism that is achieved.
Page 225 :
224, , CHAPTER 7 / BLOCK CIPHER OPERATION, ■, , ■, , ■, , ■, ■, , Software efficiency: Similarly, because of the opportunities for parallel execution in CTR mode, processors that support parallel features, such as aggressive, pipelining, multiple instruction dispatch per clock cycle, a large number of registers, and SIMD instructions, can be effectively utilized., Preprocessing: The execution of the underlying encryption algorithm does, not depend on input of the plaintext or ciphertext. Therefore, if sufficient, memory is available and security is maintained, preprocessing can be used to, prepare the output of the encryption boxes that feed into the XOR functions,, as in Figure 7.7. When the plaintext or ciphertext input is presented, then, the only computation is a series of XORs. Such a strategy greatly enhances, throughput., Random access: The ith block of plaintext or ciphertext can be processed in, random-access fashion. With the chaining modes, block Ci cannot be computed until the i - 1 prior blocks are computed. There may be applications in, which a ciphertext is stored and it is desired to decrypt just one block; for such, applications, the random access feature is attractive., Provable security: It can be shown that CTR is at least as secure as the other, modes discussed in this chapter., Simplicity: Unlike ECB and CBC modes, CTR mode requires only the implementation of the encryption algorithm and not the decryption algorithm. This, matters most when the decryption algorithm differs substantially from the encryption algorithm, as it does for AES. In addition, the decryption key scheduling need not be implemented., , Note that, with the exception of ECB, all of the NIST-approved block cipher modes of operation involve feedback. This is clearly seen in Figure 7.8. To, highlight the feedback mechanism, it is useful to think of the encryption function, as taking input from an input register whose length equals the encryption block, length and with output stored in an output register. The input register is updated, one block at a time by the feedback mechanism. After each update, the encryption algorithm is executed, producing a result in the output register. Meanwhile,, a block of plaintext is accessed. Note that both OFB and CTR produce output, that is independent of both the plaintext and the ciphertext. Thus, they are natural candidates for stream ciphers that encrypt plaintext by XOR one full block at, a time., , 7.7 XTS-AES MODE FOR BLOCK-ORIENTED, STORAGE DEVICES, In 2010, NIST approved an additional block cipher mode of operation, XTS-AES., This mode is also an IEEE standard, IEEE Std 1619-2007, which was developed, by the IEEE Security in Storage Working Group (P1619). The standard describes, a method of encryption for data stored in sector-based devices where the threat, model includes possible access to stored data by the adversary. The standard has, received widespread industry support.
Page 226 :
7.7 / XTS-AES MODE FOR BLOCK-ORIENTED STORAGE DEVICES, , 225, , Plaintext block, Input register, Key, Input register, , Encrypt, Key, , Encrypt, , Output register, , Plaintext block, , Output register, , Ciphertext, , (a) Cipher block chaining (CBC) mode, , Ciphertext, , (b) Cipher feedback (CFB) mode, , Counter, Input register, , Input register, Key, , Key, , Encrypt, , Encrypt, , Output register, , Output register, , Plaintext block, Ciphertext, , (c) Output feedback (OFB) mode, , Plaintext block, Ciphertext, , (d) Counter (CTR) mode, , Figure 7.8 Feedback Characteristic of Modes of Operation, , Tweakable Block Ciphers, The XTS-AES mode is based on the concept of a tweakable block cipher, introduced in [LISK02], which functions in much the same manner as a salt used with, passwords, as described in Chapter 22. The form of this concept used in XTS-AES, was first described in [ROGA04]., Before examining XTS-AES, let us consider the general structure of a tweakable block cipher. A tweakable block cipher is one that has three inputs: a plaintext P, a symmetric key K, and a tweak T; and produces a ciphertext output C. We, can write this as C = E(K, T, P). The tweak need not be kept secret. Whereas the
Page 227 :
226, , CHAPTER 7 / BLOCK CIPHER OPERATION, Tj, , Hash, function, , Tj, , Pj, , H(Tj), , Cj, , Hash, function, K, , K, , Encrypt, , Decrypt, , Cj, , Pj, , (a) Encryption, , (b) Decryption, , Figure 7.9 Tweakable Block Cipher, , purpose of the key is to provide security, the purpose of the tweak is to provide, variability. That is, the use of different tweaks with the same plaintext and same key, produces different outputs. The basic structure of several tweakable clock ciphers, that have been implemented is shown in Figure 7.9. Encryption can be expressed as:, C = H(T) ⊕ E(K, H(T) ⊕ P), where H is a hash function. For decryption, the same structure is used with the, plaintext as input and decryption as the function instead of encryption. To see that, this works, we can write, H(T) ⊕ C = E(K, H(T) ⊕ P), D[K, H(T) ⊕ C] = H(T) ⊕ P, H(T) ⊕ D(K, H(T) ⊕ C) = P, It is now easy to construct a block cipher mode of operation by using a different tweak value on each block. In essence, the ECB mode is used but for each block, the tweak is changed. This overcomes the principal security weakness of ECB,, which is that two encryptions of the same block yield the same ciphertext., , Storage Encryption Requirements, The requirements for encrypting stored data, also referred to as “data at rest” differ somewhat from those for transmitted data. The P1619 standard was designed to, have the following characteristics:, 1. The ciphertext is freely available for an attacker. Among the circumstances, that lead to this situation:, a. A group of users has authorized access to a database. Some of the records in, the database are encrypted so that only specific users can successfully read/, , Hiva-Network.Com
Page 228 :
7.7 / XTS-AES MODE FOR BLOCK-ORIENTED STORAGE DEVICES, , 2., 3., 4., , 5., 6., 7., , 227, , write them. Other users can retrieve an encrypted record but are unable to, read it without the key., b. An unauthorized user manages to gain access to encrypted records., c. A data disk or laptop is stolen, giving the adversary access to the encrypted, data., The data layout is not changed on the storage medium and in transit. The encrypted data must be the same size as the plaintext data., Data are accessed in fixed sized blocks, independently from each other. That is,, an authorized user may access one or more blocks in any order., Encryption is performed in 16-byte blocks, independently from other blocks, (except the last two plaintext blocks of a sector, if its size is not a multiple of, 16 bytes)., There are no other metadata used, except the location of the data blocks, within the whole data set., The same plaintext is encrypted to different ciphertexts at different locations,, but always to the same ciphertext when written to the same location again., A standard conformant device can be constructed for decryption of data encrypted by another standard conformant device., , The P1619 group considered some of the existing modes of operation for use with, stored data. For CTR mode, an adversary with write access to the encrypted media can, flip any bit of the plaintext simply by flipping the corresponding ciphertext bit., Next, consider requirement 6 and the use of CBC. To enforce the requirement, that the same plaintext encrypts to different ciphertext in different locations, the IV, could be derived from the sector number. Each sector contains multiple blocks. An, adversary with read/write access to the encrypted disk can copy a ciphertext sector from one position to another, and an application reading the sector off the new, location will still get the same plaintext sector (except perhaps the first 128 bits)., For example, this means that an adversary that is allowed to read a sector from the, second position but not the first can find the content of the sector in the first position by manipulating the ciphertext. Another weakness is that an adversary can flip, any bit of the plaintext by flipping the corresponding ciphertext bit of the previous, block, with the side-effect of “randomizing” the previous block., , Operation on a Single Block, Figure 7.10 shows the encryption and decryption of a single block. The operation involves two instances of the AES algorithm with two keys. The following parameters, are associated with the algorithm., Key, , The 256 or 512 bit XTS-AES key; this is parsed as a concatenation of two, fields of equal size called Key1 and Key2, such that Ke y = Ke y1 }Ke y2 ., , Pj, , The jth block of plaintext. All blocks except possibly the final block have a, length of 128 bits. A plaintext data unit, typically a disk sector, consists of a, sequence of plaintext blocks P1, P2, c , Pm., , Cj, , The jth block of ciphertext. All blocks except possibly the final block have a, length of 128 bits.
Page 229 :
228, , CHAPTER 7 / BLOCK CIPHER OPERATION, j, , The sequential number of the 128-bit block inside the data unit., , i, , The value of the 128-bit tweak. Each data unit (sector) is assigned a, tweak value that is a nonnegative integer. The tweak values are assigned, consecutively, starting from an arbitrary nonnegative integer., , a, , A primitive element of GF(2128) that corresponds to polynomial x, (i.e., 0000 c 0102)., , aj, , a multiplied by itself j times, in GF(2128)., , ⊕, , Bitwise XOR., , ⊗, , Modular multiplication of two polynomials with binary coefficients modulo, x128 + x7 + x2 + x + 1. Thus, this is multiplication in GF(2128)., , i, , j, , Pj, , Key2, T, , AES, Encrypt, , PP, AES, Encrypt, , Key1, , CC, , Cj, , (a) Encryption, , i, , j, , Cj, , Key2, AES, Encrypt, , T, CC, AES, Decrypt, PP, , Pj, , (b) Decryption, Figure 7.10, , XTS-AES Operation on Single Block, , Key1
Page 230 :
7.7 / XTS-AES MODE FOR BLOCK-ORIENTED STORAGE DEVICES, , 229, , In essence, the parameter j functions much like the counter in CTR mode. It, assures that if the same plaintext block appears at two different positions within a, data unit, it will encrypt to two different ciphertext blocks. The parameter i functions, much like a nonce at the data unit level. It assures that, if the same plaintext block, appears at the same position in two different data units, it will encrypt to two different ciphertext blocks. More generally, it assures that the same plaintext data unit will, encrypt to two different ciphertext data units for two different data unit positions., The encryption and decryption of a single block can be described as, , XTS-AES block, operation, , T, PP, CC, C, , =, =, =, =, , E(K2, i) ⊗ aj, P⊕T, E(K1, PP), CC ⊕ T, , T, CC, PP, P, , =, =, =, =, , E(K2, i) ⊗ aj, C⊕T, D(K1, CC), PP ⊕ T, , To see that decryption recovers the plaintext, let us expand the last line of both encryption and decryption. For encryption, we have, C = CC ⊕ T = E(K1, PP) ⊕ T = E(K1, P ⊕ T) ⊕ T, and for decryption, we have, P = PP ⊕ T = D(K1, CC) ⊕ T = D(K1, C ⊕ T) ⊕ T, Now, we substitute for C:, P =, =, =, =, , D(K1, C ⊕ T) ⊕ T, D(K1, [E(K1, P ⊕ T) ⊕ T] ⊕ T) ⊕ T, D(K1, E(K1, P ⊕ T)) ⊕ T, (P ⊕ T) ⊕ T = P, , Operation on a Sector, The plaintext of a sector or data unit is organized into blocks of 128 bits. Blocks are, labeled P0, P1, c , Pm. The last block my be null or may contain from 1 to 127 bits., In other words, the input to the XTS-AES algorithm consists of m 128-bit blocks, and possibly a final partial block., For encryption and decryption, each block is treated independently and encrypted/decrypted as shown in Figure 7.10. The only exception occurs when the, last block has less than 128 bits. In that case, the last two blocks are encrypted/decrypted using a ciphertext-stealing technique instead of padding. Figure 7.11 shows, the scheme. Pm - 1 is the last full plaintext block, and Pm is the final plaintext block,, which contains s bits with 1 … s … 127. Cm - 1 is the last full ciphertext block, and, Cm is the final ciphertext block, which contains s bits. This technique is commonly, called ciphertext stealing because the processing of the last block “steals” a temporary ciphertext of the penultimate block to complete the cipher block., Let us label the block encryption and decryption algorithms of Figure 7.10 as, Block encryption: XTS-AES-blockEnc(K, Pj, i, j), Block decryption: XTS-AES-blockDec(K, Cj, i, j)
Page 232 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 231, , As can be seen, XTS-AES mode, like CTR mode, is suitable for parallel operation. Because there is no chaining, multiple blocks can be encrypted or decrypted, simultaneously. Unlike CTR mode, XTS-AES mode includes a nonce (the parameter i) as well as a counter (parameter j)., , 7.8 FORMAT-PRESERVING ENCRYPTION, Format-preserving encryption (FPE) refers to any encryption technique that takes, a plaintext in a given format and produces a ciphertext in the same format. For, example, credit cards consist of 16 decimal digits. An FPE that can accept this type of, input would produce a ciphertext output of 16 decimal digits. Note that the ciphertext, need not be, and in fact is unlikely to be, a valid credit card number. But it will have, the same format and can be stored in the same way as credit card number plaintext., A simple encryption algorithm is not format preserving, with the exception, that it preserves the format of binary strings. For example, Table 7.2 shows three, types of plaintext for which it might be desired to perform FPE. The third row, shows examples of what might be generated by an FPE algorithm. The fourth row, shows (in hexadecimal) what is produced by AES with a given key., , Motivation, FPE facilitates the retrofitting of encryption technology to legacy applications,, where a conventional encryption mode might not be feasible because it would disrupt data fields/pathways. FPE has emerged as a useful cryptographic tool, whose, applications include financial-information security, data sanitization, and transparent encryption of fields in legacy databases., The principal benefit of FPE is that it enables protection of particular data, elements in a legacy database that did not provide encryption of those data elements, while still enabling workflows that were in place before FPE was in use. With, FPE, as opposed to ordinary AES encryption or TDEA encryption, no database, schema changes and minimal application changes are required. Only applications, that need to see the plaintext of a data element need to be modified and generally, these modifications will be minimal., Some examples of legacy applications where FPE is desirable:, ■, , COBOL data-processing applications: Any changes in the structure of a record requires corresponding changes in all code that references that record, structure. Typical code sizes involve hundreds of modules, each containing, around 5,000–10,000 lines on average., , Table 7.2, , Comparison of Format-Preserving Encryption and AES, Credit Card, , Tax ID, , Bank Account Number, , Plaintext, , 8123 4512 3456 6780, , 219-09-9999, , 800N2982K-22, , FPE, , 8123 4521 7292 6780, , 078-05-1120, , 709G9242H-35, , AES (hex), , af411326466add24, c86abd8aa525db7a, , 7b9af4f3f218ab25, 07c7376869313afa, , 9720ec7f793096ff, d37141242e1c51bd
Page 233 :
232, , CHAPTER 7 / BLOCK CIPHER OPERATION, ■, , ■, , Database applications: Fields that are specified to take only character strings, cannot be used to store conventionally encrypted binary ciphertext. Base64, encoding of such binary ciphertext is not always feasible without increase in, data lengths, requiring augmentation of corresponding field lengths., FPE-encrypted characters can be significantly compressed for efficient transmission. This cannot be said about AES-encrypted binary ciphertext., , Difficulties in Designing an FPE, A general-purpose standardized FPE should meet a number of requirements:, 1. The ciphertext is of the same length and format as the plaintext., 2. It should be adaptable to work with a variety of character and number types., Examples include decimal digits, lowercase alphabetic characters, and the full, character set of a standard keyboard or international keyboard., 3. It should work with variable plaintext lengths., 4. Security strength should be comparable to that achieved with AES., 5. Security should be strong even for very small plaintext lengths., Meeting the first requirement is not at all straightforward. As illustrated in, Table 7.2, a straightforward encryption with AES yields a 128-bit binary block that, does not resemble the required format. Also, a standard symmetric block cipher is, not easily adaptable to produce an FPE., Consider a simple example. Assume that we want an algorithm that can encrypt decimal digit strings of maximum length of 32 digits. The input to the algorithm can be stored in 16 bytes (128 bits) by encoding each digit as four bits and, using the corresponding binary value for each digit (e.g., 6 is encoded as 0101)., Next, we use AES to encrypt the 128-bit block, in the following fashion:, 1. The plaintext input X is represented by the string of 4-bit decimal digits, X[1] . . . X[16]. If the plaintext is less than 16 digits long, it is padded out to the, left (most significant) with zeros., 2. Treating X as a 128-bit binary string and using key K, form ciphertext, Y = AESK(X)., 3. Treat Y as a string of length 16 of 4-bit elements., 4. Some of the entries in Y may have values greater than 9 (e.g., 1100). To generate ciphertext Z in the required format, calculate, Z[i] = Y[i] mod 10,, , 1 … i … 16, , This generates a ciphertext of 16 decimal digits, which conforms to the desired format. However, this algorithm does not meet the basic requirement of, any encryption algorithm of reversibility. It is impossible to decrypt Z to recover, the original plaintext X because the operation is one-way; that is, it is a manyto-one function. For example, 12 mod 10 = 2 mod 10 = 2. Thus, we need to design a reversible function that is both a secure encryption algorithm and format, preserving.
Page 234 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 233, , A second difficulty in designing an FPE is that some of the input strings are, quite short. For example, consider the 16-digit credit card number (CCN). The first, six digits provide the issuer identification number (IIN), which identifies the institution that issued the card. The final digit is a check digit to catch typographical, errors or other mistakes. The remaining nine digits are the user’s account number., However, a number of applications require that the last four digits be in the clear, (the check digit plus three account digits) for applications such as credit card receipts, which leaves only six digits for encryption. Now suppose that an adversary, is able to obtain a number of plaintext/ciphertext pairs. Each such pair corresponds, to not just one CCN, but multiple CCNs that have the same middle six digits. In a, large database of credit card numbers, there may be multiple card numbers with, the same middle six digits. An adversary may be able to assemble a large dictionary mapping known as six-digit plaintexts to their corresponding ciphertexts. This, could be used to decrypt unknown ciphertexts from the database. As pointed out, in [BELL10a], in a database of 100 million entries, on average about 100 CCNs, will share any given middle-six digits. Thus, if the adversary has learned k CCNs, and gains access to such a database, the adversary can decrypt approximately, 100k CCNs., The solution to this second difficulty is to use a tweakable block cipher; this, concept is described in Section 7.7. For example, the tweak for CCNs could be the, first two and last four digits of the CCN. Prior to encryption, the tweak is added,, digit-by-digit mod 10, to the middle six-digit plaintext, and the result is then encrypted. Two different CCNs with identical middle six digits will yield different, tweaked inputs and therefore different ciphertexts. Consider the following:, CCN, , Tweak, , Plaintext, , Plaintext + Tweak, , 4012 8812 3456 1884, , 401884, , 123456, , 524230, , 5105 1012 3456 6782, , 516782, , 123456, , 639138, , Two CCNs with the same middle six digits have different tweaks and therefore different values to the middle six digits after the tweak is added., , Feistel Structure for Format-Preserving Encryption, As the preceding discussion shows, the challenge with FPE is to design an algorithm for scrambling the plaintext that is secure, preserves format, and is reversible., A number of approaches have been proposed in recent years [ROGA10, BELL09], for FPE algorithms. The majority of these proposals use a Feistel structure., Although IBM introduced this structure with their Lucifer cipher [SMIT71] almost, half a century ago, it remains a powerful basis for implementing ciphers., This section provides a general description of how the Feistel structure can, be used to implement an FPE. In the following section, we look at three specific, Feistel-based algorithms that are in the process of receiving NIST approval., ENCRYPTION AND DECRYPTION Figure 7.12 shows the Feistel structure used in all of, the NIST algorithms, with encryption shown on the left-hand side and decryption, on the right-hand side. The structure in Figure 7.12 is the same as that shown in
Page 235 :
CHAPTER 7 / BLOCK CIPHER OPERATION, , A1, , n, T, 1, , Round r–1, , B0, , FK, , +, , B2, , Ar–2, , n, T, r–2, , FK, Cr–2, , Round r–1, , Br–1, , Cr–2, n, T, r–1, , Ar–1, FK, , Br–2, , +, Cr–1, , Ar, , Br–1, , Br, , Cr–1, , A1, , C1, , B2, , Cr–2, –, , n, T, r–1, , Ar–1, , n, T, i–2, , FK, , Ar, , A3, , Br–2, , Ci–2, , Br–1, , C1, , FK, , C2, , A2, , Br–2, , +, , A2, n, T, 1, , Round 1, , Round r–2, , Ar–2, , C1, , n, T, 0, , FK, , B1, , C1, B1, , A2, , C0, –, , Round r–2, , C0, , Round 1, , B1, , n, T, 0, , FK, , Round 0, , Round 0, , +, C0, , Output (plaintext), u characters, v characters, B0, A0, C0, A1, , Ar–1, , Cr–1, Cr–1, , FK, , Ar, , –, , Input (plaintext), u characters, v characters, B0, A0, , –, , 234, , Br, , Output (ciphertext), , Input (ciphertext), , (a) Encryption, , (b) Decryption, , Figure 7.12 Feistel Structure for Format-Preserving Encryption, , Figure 4.3 but, to simplify the presentation, it is untwisted, not illustrating the swap, that occurs at the end of each round., The input to the encryption algorithm is a plaintext character string of, n = u + v characters. If n is even, then u = v, otherwise u and v differ by 1. The, two parts of the string pass through an even number of rounds of processing to, produce a ciphertext block of n characters and the same format as the plaintext., Each round i has inputs Ai and Bi, derived from the preceding round (or plaintext, for round 0)., All rounds have the same structure. On even-numbered rounds, a substitution, is performed on the left part (length u) of the data, Ai. This is done by applying the, round function FK to the right part (length v) of the data, Bi, and then performing
Page 236 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 235, , a modular addition of the output of FK with Ai. The modular addition function and, the selection of modulus are described subsequently. On odd-numbered rounds,, the substitution is done on the right part of the data. FK is a one-way function that, converts the input into a binary string, performs a scrambling transformation on the, string, and then converts the result back into a character string of suitable format, and length. The function has as parameters the secret key K, the plaintext length n,, a tweak T, and the round number i., Note that on even-numbered rounds, FK has an input of v characters, and that, the modular addition produces a result of u characters, whereas on odd-numbered, rounds, FK has an input of u characters, and that the modular addition produces a, result of v characters. The total number of rounds is even, so that the output consists, of an A portion of length u concatenated with a B portion of length v, matching the, partition of the plaintext., The process of decryption is essentially the same as the encryption process., The differences are: (1) the addition function is replaced by a subtraction function, that is its inverse; and (2) the order of the round indices is reversed., To demonstrate that the decryption produces the correct result, Figure 7.12b, shows the encryption process going down the left-hand side and the decryption process going up the right-hand side. The diagram indicates that, at every round, the, intermediate value of the decryption process is equal to the corresponding value of, the encryption process. We can walk through the figure to validate this, starting at, the bottom. The ciphertext is produced at the end of round r - 1 as a string of the, form Ar } Br, with Ar and Br having string lengths u and v, respectively. Encryption, round r - 1 can be described with the following equations:, Ar = Br - 1, Br = Ar - 1 + FK[Br - 1], Because we define the subtraction function to be the inverse of the addition, function, these equations can be rewritten:, Br - 1 = Ar, Ar - 1 = Br - FK[Br - 1], It can be seen that the last two equations describe the action of round 0 of the, decryption function, so that the output of round 0 of decryption equals the input, of round r - 1 of encryption. This correspondence holds all the way through the r, iterations, as is easily shown., Note that the derivation does not require that F be a reversible function. To, see this, take a limiting case in which F produces a constant output (e.g., all ones), regardless of the values of its input. The equations still hold., CHARACTER STRINGS The NIST algorithms, and the other FPE algorithms that have, been proposed, are used with plaintext consisting of a string of elements, called, characters. Specifically, a finite set of two or more symbols is called an alphabet,, and the elements of an alphabet are called characters. A character string is a finite, sequence of characters from an alphabet. Individual characters may repeat in the, string. The number of different characters in an alphabet is called the base, also, , Hiva-Network.Com
Page 237 :
236, , CHAPTER 7 / BLOCK CIPHER OPERATION, , referred to as the radix of the alphabet. For example, the lowercase English alphabet a, b, c, . . . has a radix, or base, of 26. For purposes of encryption and decryption,, the plaintext alphabet must be converted to numerals, where a numeral is a nonnegative integer that is less than the base. For example, for the lowercase alphabet,, the assignment could be characters a, b, c, . . . , z map into 0, 1, 2, . . . , 25., A limitation of this approach is that all of the elements in a plaintext format, must have the same radix. So, for example, an identification number that consists, of an alphabetic character followed by nine numeric digits cannot be handled in, format-preserving fashion by the FPEs that have been implemented so far., The NIST document defines notation for specifying these conversions, (Table 7.3a). To begin, it is assumed that the character string is represented by, a numeral string. To convert a numeral string X into a number x, the function, NUM radix(X) is used. Viewing X as the string X[1] . . . X [m] with the most significant numeral first, the function is defined as, m, , m-1, , NUM radix(X) = a X[i] radixm - i = a X[m - i] radixi, i=1, , i=0, , m, , Observe that 0 … NUM radix(X) 6 radix and that 0 … X[i] 6 radix., Table 7.3, [x], , Notation and Parameters Used in FPE Algorithms, , s, , Converts an integer into a byte string; it is the string of s bytes that encodes the, number x, with 0 … x 6 28s. The equivalent notation is STR8s, 2 (x)., , LEN(X), , Length of the character string X., , NUM radix(X), , Converts strings to numbers. The number that the numeral string X represents, in base radix, with the most significant character first. In other words, it is the, nonnegative integer less than radixLEN(X) whose most-significant-character-first, representation in base radix is X., , PRFK(X), , A pseudorandom function that produces a 128-bit output with X as the input,, using encryption key K., , STRm, radix(x), , Given a nonnegative integer x less than radixm, this function produces a representation of x as a string of m characters in base radix, with the most significant, character first., , [i .. j], , The set of integers between two integers i and j, including i and j., , X[i .. j], , The substring of characters of a string X from X[i] to X[j], including X[i] and X[j]., , REV(X), , Given a bit string, X, the string that consists of the bits of X in reverse order., , (a) Notation, radix, , The base, or number of characters, in a given plaintext alphabet., , tweak, , Input parameter to the encryption and decryption functions whose confidentiality, is not protected by the mode., , tweakradix, , The base for tweak strings, , minlen, , Minimum message length, in characters., , maxlen, , Maximum message length, in characters., , maxTlen, , Maximum tweak length, , (b) Parameters
Page 238 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 237, , For example, consider the string zaby in radix 26, which converts to the, numeral string 25 0 1 24. This converts to the number x = (25 * 26 3) + (1 * 261), + 2 4 = 4 3 9 4 5 0 . To go in the opposite direction and convert from a number, x 6 radixm to a numeral string X of length m, the function STRm, radix(x) is used:, STRm, radix(x) = X[1] c X[m], where, X[i] = j, , x, k mod radix, i = 1, c, m, radixm - i, , With the mapping of characters to numerals and the use of the NUM function, a plaintext character string can be mapped to a number and stored as an, unsigned integer. We would like to treat this unsigned integer as a bit string that, can be input to a bit-scrambling algorithm in FK. However, different platforms store, unsigned integers differently, some in little-endian and some in big-endian fashion., So one more step is needed. By the definition of the STR function, STR8s, 2 (x) will, generate a bit string of length 8s, equivalently a byte string of length s, which is a, binary integer with the most significant bit first, regardless of how x is stored as an, unsigned integer. For convenience the following notation is used: [x]s = STR8s, 2 (x)., Thus, [NUM radix(X)]s will convert the character string X into an unsigned integer, and then convert that to a byte string of length s bytes with the most significant, bit first., Continuing, the preceding example should help clarify the issues involved., Character string, , “zaby”, , Numeral string X representation of, character string, , 25 0 1 24, , Convert X to number, x = NUM 26(X), , decimal: 439450, hex: 6B49A, binary: 1101011010010011010, , x stored on big-endian byte order, machine as a 32-bit unsigned, integer, , hex: 00 06 B4 9A, binary: 00000000000001101011010010011010, , x stored on little-endian byte, order machine as a 32-bit unsigned, integer, , hex: 9A B4 06 00, binary: 10011010101101000000011000000000, , Convert x, regardless of endian, format, to a bit string of length, 32 bits (4 bytes), expressed as [x]4, , 00000000000001101011010010011010, , THE FUNCTION FK We can now define in general terms the function FK. The, core of FK is some type of randomizing function whose input and output are bit, strings. For convenience, the strings should be multiples of 8 bits, forming byte, strings. Define m to be u for even rounds and v for odd rounds; this specifies, the desired output character string length. Define b to be the number of bytes, needed to store the number representing a character string of m bytes. Then the
Page 239 :
238, , CHAPTER 7 / BLOCK CIPHER OPERATION, , round, including FK, consists of the following general steps (A and B refer to Ai, and Bi for round i):, 1. Q d [NUM radix(B)]b, , Converts numeral string X into byte string Q of, length b bytes., , 2. Y d RAN[Q], , A pseudorandom function PRNF that produces, a pseudorandom byte string Y as a function of, the bits of Q., Converts Y into unsigned integer., , 3. y d NUM 2(Y), 4. c d (NUM radix(A) + y) mod radix, , m, , Converts numeral string A into an integer and, adds to y, modulo radixm., , 5. C d STRm, radix(c), , Converts c into a numeral string C of length m., , 6. A d B;, BdC, , Completes the round by placing the unchanged, value of B from the preceding round into A, and, placing C into B., , Steps 1 through 3 constitute the round function FK. Step 3 is presented with Y,, which is an unstructured bit string. Because different platforms may store unsigned, integers using different word lengths and endian conventions, it is necessary to perform NUM 2(Y) to get an unsigned integer y. The stored bit sequence for y may or, may not be identical to the bit sequence for Y., As mentioned, the pseudorandom function in step 2 need not be reversible. Its, purpose is to provide a randomized, scrambled bit string. For DES, this is achieved, by using fixed S-boxes, as described in Appendix S. Virtually all FPE schemes that, use the Feistel structure use AES as the basis for the scrambling function to achieve, stronger security., RELATIONSHIP BETWEEN RADIX, MESSAGE LENGTH, AND BIT LENGTH Consider, a numeral string X of length len and base radix. If we convert this to a number, x = NUM radix(X), then the maximum value of x is radixlen - 1. The number of bits, needed to encode x is, bitlen = < LOG2(radixlen) = = < lenLOG2(radix) =, Observe that an increase in either radix or len increases bitlen. Often, we want, to limit the value of bitlen to some fixed upper limit, for example, 128 bits, which is, the size of the input to AES encryption. We also want the FPE to handle a variety of, radix values. The typical FPE, and all of those discussed subsequently, allow a given, range of radix values and then define a maximum character string length in order to, provide the algorithm with a fixed value of bitlen. Let the range of radix values be, from 2 to maxradix, and the maximum allowable character string value be maxlen., Then the following relationship holds:, maxlen … : bitlen/LOG2(radix) ; , or equivalently, maxlen … : bitlen * LOGradix(2) ;, For example, for a radix of 10, maxlen … : 0.3 * bitlen ; ; for a radix of 26,, maxlen … : 0.21 * bitlen ; . The larger the radix, the smaller the maximum character length for a given bit length.
Page 240 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 239, , NIST Methods for Format-Preserving Encryption, In 2013, NIST issued SP 800-38G: Recommendation for Block Cipher Modes of, Operation: Methods for Format-Preserving Encryption. This Recommendation, specifies three methods for format-preserving encryption, called FF1, FF2, and FF3., The three methods all use the Feistel structure shown in Figure 7.12. They employ, somewhat different round functions FK, which are built using AES. Important differences are the following:, ■, , ■, , ■, , FF1 supports the greatest range of lengths for the plaintext character string, and the tweak. To achieve this, the round function uses a cipher-block-chaining, (CBC) style of encryption, whereas FF2 and FF3 employ simple electronic, codebook (ECB) encryption., FF2 uses a subkey generated from the encryption key and the tweak, whereas, FF1 and FF3 use the encryption key directly. The use of a subkey may help, protect the original key from side-channel analysis, which is an attack based, on information gained from the physical implementation of a cryptosystem,, rather than brute force or cryptanalysis. Examples of such attacks are attempts, to deduce key bits based on power consumption or execution time., FF3 offers the lowest round count, eight, compared to ten for FF1 and FF2,, and is the least flexible in the tweaks that it supports., , ALGORITHM FF1 Algorithm FF1 was submitted to NIST as a proposed FPE mode, [BELL10a, BELL10b] with the name FFX[Radix]. FF1 uses a pseudorandom function PRFK(X) that produces a 128-bit output with inputs X that is a multiple of 128, bits and encryption key K (Figure 7.13). In essence, PRFK(X) use CBC encryption, (Figure 7.4) with X as the plaintext input, encryption key K, and an initial vector, (IV) of all zeros. The output is the last block of ciphertext produced. This is also, , Prerequisites:, Approved, 128-bit block cipher, CIPH;, Key, K, for the block cipher;, Input:, Nonempty bit string, X, such that LEN(X) is a multiple of 128., Output:, 128-bit block, Y, Steps:, 1., 2., 3., 4., 4.i, 6., , Let m = LEN(X)/128., Partition X into m 128-bit blocks X1, c , Xm, so that X = X1 } c }Xm, Let Y0 = [0]16, For j from 1 to m:, let Yj = CIPH K(Yj - 1 ⊕ Xj)., Return Ym., , Figure 7.13 Algorithm PRF(X)
Page 241 :
240, , CHAPTER 7 / BLOCK CIPHER OPERATION, , equivalent to the message authentication code known as CBC-MAC, or CMAC,, described in Chapter 12., The FF1 encryption algorithm is illustrated in Figure 7.14. The shaded lines, correspond to the function FK. The algorithm has 10 rounds and the following, parameters (Table 7.3b):, ■, ■, ■, ■, , ■, , radix ∈ [2 .. 216], radixminlen Ú 100, minlen Ú 2, maxlen 6 232. For the maximum radix value of 216, the maximum bit length to, store the integer value of X is 16 * 232 bits; for the minimum radix value of 2,, the maximum bit length to store the integer value of X is 232 bits., maxTlen 6 232, , The inputs to the encryption algorithm are a character string X of length n, and a tweak T of length t. The tweak is optional in that it may be the empty string., Prerequisites:, Approved, 128-bit block cipher, CIPH;, Key, K, for the block cipher;, Base, radix, for the character alphabet;, Range of supported message lengths, [minlen .. maxlen];, Maximum byte length for tweaks, maxTlen., Inputs:, Character string, X, in base radix of length n such that n ∈ [minlen .. maxlen];, Tweak T, a byte string of byte length t, such that t ∈ [0 .. maxTlen]., Output:, Character string, Y, such that LEN(Y) = n., Steps:, 1., 2., 3., 4., 5., , Let u = : n/2 ; ; v = n - u., Let A = X[1 .. u]; B = X[u + 1 .. n]., Let b = < < v LOG2(radix) = /8 = ; d = 4 < b/4 = + 4, Let P = [1]1 } [2]1 } [1]1 } [radix]3 } [10]1 } [u mod 256]1 } [n]4 } [t]4., For i from 0 to 9:, i. Let Q = T } [0](-t - b - 1) mod 16 } [i]1 } [NUM radix(B)]b., ii. Let R = PRFK(P}Q)., iii. Let S be the first d bytes of the following string of [d/16] 128-bit blocks:, R } CIPH K(R ⊕ [1]16) } CIPH K(R ⊕ [2]16) } c } CIPH K(R ⊕ [ < d/16 = - 1]16)., iv. Let y = NUM 2(S)., v. If i is even, let m = u; else, let m = v., , vi. Let c = (NUM radix(A) + y) mod radixm., vii. Let C = STRm, radix(c)., viii. Let A = B., ix. Let B = C., 6. Return Y = A}B., , Figure 7.14 Algorithm FF1 (FFX[Radix])
Page 242 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 241, , The output is the encrypted character string Y of length n. What follows is a step-bystep description of the algorithm., 1., 2. The input X is split into two substrings A and B. If n is even, A and B are, of equal length. Otherwise, B is one character longer than A., 3. The expression < v LOG2(radix) = equals the number of bits needed to, encode B, which is v characters long. Encoding B as a byte string, b is, the number of bytes in the encoding. The definition of d ensures that the, output of the Feistel round function is at least 4 bytes longer than this, encoding of B, which minimizes any bias in the modular reduction in, step 5.vi, as explained subsequently., 4. P is a 128-bit (16-byte) block that is a function of radix, u, n, and t. It, serves as the first block of plaintext input to the CBC encryption mode, used in 5.ii, and is intended to increase security., 5. The loop through the 10 rounds of encryption., 5.i The tweak, T, the substring, B, and the round number, i, are encoded, as a binary string, Q, which is one or more 128-bit blocks in length. To, understand this step, first note that the value NUM radix(B) produces a, numeral string that represents B in base radix. How this numeral string is, formatted and stored is outside the scope of the standard. Then, the value, [NUM radix(B)]b produces the representation of the numerical value of B, as a binary number in a string of b bytes. We also have the length of T, is t bytes, and the round number is stored in a single byte. This yields a, length of (t + b + 1) bytes. This is padded out with z = ( -t - b - 1), mod 16 bytes. From the rules of modular arithmetic, we know that, (z + t + b + 1) mod 16 = 0. Thus the length of Q is one or more 128bit blocks., 5.ii The concatenation of P and Q is input to the pseudorandom function PRF to produce a 128-bit output R. This function is the pseudorandom core of the Feistel round function. It scrambles the bits of Bi, (Figure 7.12)., 5.iii This step either truncates or expands R to a byte string S of length d, bytes. That is, if d … 16 bytes, then R is the first d bytes of R. Otherwise, the 16-byte R is concatenated with successive encryptions of R XORed, with successive constants to produce the shortest string of 16-byte blocks, whose length is greater than or equal to d bytes., 5.iv This step begins the process of converting the results of the scrambling, of Bi into a form suitable for combining with Ai. In this step, the d-byte, string S is converted into a numeral string in base 2 that represents S., That is, S is represented as a binary string y., 5.v This step determines the length m of the character string output that is, required to match the length of the B portion of the round output. For, even-numbered rounds, the length is u characters, and for odd-numbered, rounds it is v characters, as shown in Figure 7.12., 5.vi The numerical values of A and y are added modulo radixm. This truncates the value of the sum to a value c that can be stored in m characters.
Page 243 :
242, , CHAPTER 7 / BLOCK CIPHER OPERATION, , 5.vii This step converts the c into the proper representation C as a string of m, characters., 5.viii, 5.ix These steps complete the round by placing the unchanged value of B, from the preceding round into A, and placing C into B., 6. After the final round, the result is returned as the concatenation of A and B., It may be worthwhile to clarify the various uses of the NUM function in FF1., NUM converts strings with a given radix into integers. In step 5.i, B is a character, string in base radix, so NUM radix(B) converts this into an integer, which is stored, as a byte string, suitable for encryption in step 5.ii. For step 5.iv, S is a byte string, output of an encryption function, which can be viewed a bit string, so NUM 2(S), converts this into an integer., Finally, a brief explanation of the variable d is in order, which is best explained by example. Let radix = 26 and v = 30 characters. Then b = 18 bytes,, and d = 24 bytes. Step 5.ii produces an output R of 16 bytes. We desire a scrambled output of b bytes to match the input, and so R needs to be padded out. Rather, than padding with a constant value such as all zeros, step 5.iii pads out with random, bits. The result, in step 5.iv is a number greater than radixm of fully randomized, bits. The use of randomized padding avoids a potential security risk of using a fixed, padding., ALGORITHM FF2 Algorithm FF2 was submitted to NIST as a proposed FPE, mode with the name VAES3 [VANC11]. The encryption algorithm is defined in, Figure 7.15. The shaded lines correspond to the function FK. The algorithm has the, following parameters:, ■, ■, ■, ■, ■, , ■, , ■, , radix ∈ [2 .. 28], tweakradix ∈ [2 .. 28], radixminlen Ú 100, minlen Ú 2, maxlen … 2 : 120/LOG2(radix) ; if radix is a power of 2. For the maximum radix, value of 28, maxlen … 30; for the minimum radix value of 2, maxlen … 240. In, both cases, the maximum bit length to store the integer value of X is 240 bits,, or 30 bytes., maxlen … 2 : 98/LOG2(radix) ; if radix is a not a power of 2. For the maximum radix value of 255, maxlen … 24; for the minimum radix value of 3,, maxlen … 124., maxTlen … : 104/LOG2(tweakradix) ; . For the maximum tweakradix value of, 28, maxTlen … 13., , For FF2, the plaintext character alphabet and that of the tweak may be different., The first two steps of FF2 are the same as FF1, setting values for v, u, A, and B., FF2 proceeds with the following steps:, 3., , P is a 128-bit (16-byte) block. If there is a tweak, then P is a function of, radix, t, n, and the 13-byte numerical value of the tweak. If there is no tweak, (t = 0), then P is a function of radix and n. P is used to form an encryption key, in step 4.
Page 244 :
7.8 / FORMAT-PRESERVING ENCRYPTION, , 243, , Approved, 128-bit block cipher, CIPH;, Key, K, for the block cipher;, Base, tweakradix, for the tweak character alphabet;, Range of supported message lengths, [minlen .. maxlen];, Maximum supported tweak length, maxTlen., Inputs:, Numeral string, X, in base radix, of length n such that n ∈ [minlen .. maxlen];, Tweak numeral string, T, in base tweakradix, of length t such that t ∈ [0 .. maxTlen]., Output:, Numeral string, Y, such that LEN(Y) = n., Steps:, 1., 2., 3., 4., 5., , Let u = : n/2 ; ; v = n - u., Let A = X[1 .. u]; B = X[u + 1 .. n]., If t 7 0, P = [radix]1 } [t]1 } [n]1 } [NUM tweakradix(T)]13; else P = [radix]1 } [0]1 } [n]1 } [0]13., Let J = CIPH K(P)., For i from 0 to 9:, i., ii., iii., iv., , Let Q d [i]1 } [NUM radix(B)]15, Let Y d CIPH J(Q)., Let y d NUM 2(Y)., If i is even, let m = u; else, let m = v., , v. Let c = (NUM radix(A) + y) mod radixm., vi. Let C = STRm, radix(c)., vii. Let A = B., viii. Let B = C., 6. Return Y = A}B., , Figure 7.15 Algorithm FF2 (VAES3), , 4. J is the encryption of P using the input key K., 5. The loop through the 10 rounds of encryption., 5.i B is converted into a 15-byte number, prepended by the round number to, form a 16-byte block Q., 5.ii Q is encrypted using the encryption key J to yield Y., The remaining steps are the same as for FF1. The essential difference is in the, way in which all of the parameters are incorporated into the encryption that takes, place in the block FK. In both cases, the encryption is not simply an encryption of B, using key K. For FF1, B is combined with the tweak, the round number, t, n, u, and, radix to form a string of multiple 16-byte blocks. Then CBC encryption is used with, K to produce a 16-byte output. For FF2, all of the parameters besides B are combined to form a 16-byte block, which is then encrypted with K to form the key value, J. J is then used as the key for the one-block encryption of B., The structure of FF2 explains the maximum length restrictions. In step 3, P, incorporates the radix, tweak length, the numeral string length, and the tweak into, the calculation. As input to AES, P is restricted to 16 bytes. With a maximum radix, value of 28, the radix value can be stored in one byte (byte value 0 corresponds, to 256). The string length n and tweak length t each easily fits into one byte. This, leaves a restriction that the value of the tweak should be stored in at most 13 bytes,
Page 245 :
244, , CHAPTER 7 / BLOCK CIPHER OPERATION, , or 104 bits. The number of bits to store the tweak is LOG2(tweakradixTlen). This, leads to the restriction maxTlen Ú : 104/LOG2(tweakradix) ; . Similarly step 5i, incorporates B and the round number into a 16-byte input to AES, leaving, 15 bytes to encode B, or 120 bits, so that the length must be less than or equal to, : 120/LOG2(radix) ; . The parameter maxlen refers to the entire block, consisting of, partitions A and B, thus maxlen Ú 2 : 120/LOG2(radix) ; ., There is a further restriction on maxlen for a radix that is not a power of 2., As explained in [VANC11], when the radix is not a power of 2, modular arithmetic causes the value (y mod radixm) to not have uniform distribution in the output, space, which can result in a cryptographic weakness., ALGORITHM FF3 Algorithm FF3 was submitted to NIST as a proposed FPE mode, with the name BPS-BC [BRIE10]. The encryption algorithm is illustrated in, Figure 7.16. The shaded lines correspond to the function FK. The algorithm has the, following parameters:, ■, ■, ■, , radix ∈ [2 .. 216], radixminlen Ú 100, minlen Ú 2, , Approved, 128-bit block cipher, CIPH;, Key, K, for the block cipher;, Base, radix, for the character alphabet such that radix ∈ [2..216];, Range of supported message lengths, [minlen .. maxlen], such that minlen Ú 2 and, maxlen … 2 : log radix(296) ; ., Inputs:, Numeral string, X, in base radix of length n such that n ∈ [minlen .. maxlen];, Tweak bit string, T, such that LEN(T) = 64., Output:, Numeral string, Y, such that LEN(Y) = n., Steps:, 1., 2., 3., 4., , Let u = < n/2 = ; v = n - u., Let A = X[1 .. u]; B = X[u + 1 .. n]., Let TL = T[0 .. 31] and TR = T[32 .. 63]., For i from 0 to 7:, i., ii., iii., iv., , If i is even, let m = u and W = TR, else let m = v and W = TL., Let P = REV([NUM radix(REV(B))]12) } [W ⊕ REV([i]4])., Let Y = CIPH K(P)., Let y = NUM 2(REV(Y))., , v. Let c = (NUM radix(REV(A)) + y) mod radixm., vi. Let C = REV(STRm, radix(c))., vii. Let A = B., viii. Let B = C., 5. Return A}B., , Figure 7.16 Algorithm FF3 (BPS-BC), , Hiva-Network.Com
Page 246 :
7.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, ■, , ■, , 245, , maxlen … 2 : LOGradix(296) ; . For the maximum radix value of 216, maxlen … 12;, for the minimum radix value of 2, maxlen … 192. In both cases, the maximum, bit length to store the integer value of X is 192 bits, or 24 bytes., Tweak length = 64 bits, FF3 proceeds with the following steps:, , 1., 2. The input X is split into two substrings A and B. If n is even, A and B are, of equal length. Otherwise, A is one character longer than B, in contrast, to FF1 and FF2, where B is one character longer than A., The tweak is partitioned into a 32-bit left tweak TL and a 32-bit right, tweak TR., 4., The loop through the 8 rounds of encryption., 4.i As in FF1 and FF2, this step determines the length m of the character, string output that is required to match the length of the B portion of the, round output. The step also determines whether TL or TR will be used as, W in step 4ii., 4.ii The bits of B are reversed, then NUM radix(B) produces a 12-byte numeral, string in base radix; the results are again reversed. A 32-bit encoding of, the round number i is stored in a 4-byte unit, which is reversed and then, XORed with W. P is formed by concatenating these two results to form a, 16-byte block., 4.iii P is encrypted using the encryption key K to yield Y., 4.iv This is similar to step 5.iv in FF1, except that Y is reversed before converting it into a numeral string in base 2., 4.v The numerical values of the reverse of A and y are added modulo radixm., This truncates the value of the sum to a value c that can be stored in m, characters., 4.vi This step converts c to a numeral string C., 3., , The remaining steps are the same as for FF1., , 7.9 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, block cipher modes of, operation, cipher block chaining mode, (CBC), cipher feedback mode, (CFB), , ciphertext stealing, counter mode (CTR), electronic codebook mode, (ECB), meet-in-the-middle attack, nonce, , output feedback mode, (OFB), Triple DES (3DES), tweakable block cipher, XTS-AES mode
Page 247 :
246, , CHAPTER 7 / BLOCK CIPHER OPERATION, , Review Questions, 7.1, 7.2, 7.3, 7.4, 7.5, , What is triple encryption?, What is a meet-in-the-middle attack?, How many keys are used in triple encryption?, List and briefly define the block cipher modes of operation., Why do some block cipher modes of operation only use encryption while others use, both encryption and decryption?, , Problems, 7.1, , 7.2, , You want to build a hardware device to do block encryption in the cipher block chaining (CBC) mode using an algorithm stronger than DES. 3DES is a good candidate., Figure 7.17 shows two possibilities, both of which follow from the definition of CBC., Which of the two would you choose:, a. For security?, b. For performance?, Can you suggest a security improvement to either option in Figure 7.17, using only, three DES chips and some number of XOR functions? Assume you are still limited to, two keys., , Pn, , Pn, , Cn-1, , K1, K2, , EDE, , An-1, , K1, , E, , An, , Cn, , Bn-1, , (a) One-loop CBC, , K2, , D, , Bn, , K1, , Cn-1, , E, , Cn, (b) Three-loop CBC, , Figure 7.17, , Use of Triple DES in CBC Mode
Page 248 :
7.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 7.3, , 7.4, , 7.5, 7.6, , 7.7, , 7.8, 7.9, , 7.10, , 7.11, , 7.12, , 7.13, 7.14, , 247, , The Merkle–Hellman attack on 3DES begins by assuming a value of A = 0, (Figure 7.1b). Then, for each of the 256 possible values of K1, the plaintext P that, produces A = 0 is determined. Describe the rest of the algorithm., With the ECB mode, if there is an error in a block of the transmitted ciphertext, only, the corresponding plaintext block is affected. However, in the CBC mode, this error, propagates. For example, an error in the transmitted C1 (Figure 7.4) obviously corrupts P1 and P2., a. Are any blocks beyond P2 affected?, b. Suppose that there is a bit error in the source version of P1. Through how many, ciphertext blocks is this error propagated? What is the effect at the receiver?, Is it possible to perform encryption operations in parallel on multiple blocks of plaintext in CBC mode? How about decryption?, CBC-Pad is a block cipher mode of operation used in the RC5 block cipher, but it, could be used in any block cipher. CBC-Pad handles plaintext of any length. The, ciphertext is longer then the plaintext by at most the size of a single block. Padding is, used to assure that the plaintext input is a multiple of the block length. It is assumed, that the original plaintext is an integer number of bytes. This plaintext is padded at, the end by from 1 to bb bytes, where bb equals the block size in bytes. The pad bytes, are all the same and set to a byte that represents the number of bytes of padding. For, example, if there are 8 bytes of padding, each byte has the bit pattern 00001000. Why, not allow zero bytes of padding? That is, if the original plaintext is an integer multiple, of the block size, why not refrain from padding?, For the ECB, CBC, and CFB modes, the plaintext must be a sequence of one or more, complete data blocks (or, for CFB mode, data segments). In other words, for these, three modes, the total number of bits in the plaintext must be a positive multiple of, the block (or segment) size. One common method of padding, if needed, consists of a, 1 bit followed by as few zero bits, possibly none, as are necessary to complete the final, block. It is considered good practice for the sender to pad every message, including, messages in which the final message block is already complete. What is the motivation for including a padding block when padding is not needed?, If a bit error occurs in the transmission of a ciphertext character in 8-bit CFB mode,, how far does the error propagate?, In discussing OFB, it was mentioned that if it was known that two different messages, had an identical block of plaintext in the identical position, it is possible to recover, the corresponding Oi block. Show the calculation., In discussing the CTR mode, it was mentioned that if any plaintext block that is, encrypted using a given counter value is known, then the output of the encryption, function can be determined easily from the associated ciphertext block. Show the, calculation., Padding may not always be appropriate. For example, one might wish to store the, encrypted data in the same memory buffer that originally contained the plaintext. In that, case, the ciphertext must be the same length as the original plaintext. We saw the use, of ciphertext stealing in the case of XTS-AES to deal with partial blocks. Figure 7.18a, shows the use of ciphertext stealing to modify CBC mode, called CBC-CTS., a. Explain how it works., b. Describe how to decrypt Cn - 1 and Cn., Figure 7.18b shows an alternative to CBC-CTS for producing ciphertext of equal, length to the plaintext when the plaintext is not an integer multiple of the block size., a. Explain the algorithm., b. Explain why CBC-CTS is preferable to this approach illustrated in Figure 7.18b., Draw a figure similar to those of Figure 7.8 for XTS-AES mode., Work out the following problems from first principles without converting to binary, and counting the bits. Then compare with the formulae presented for encoding a
Page 249 :
248, , CHAPTER 7 / BLOCK CIPHER OPERATION, , +, , K, , PN-2, , PN-1, , CN-3, , +, , +, , K, , Encrypt, , P1, , IV, , , , Encrypt, , C1, , K, , 00…0, , +, , K, , Encrypt, , CN, , CN-2, , PN, , Encrypt, , CN-1, , X, , (a) Ciphertext stealing mode, , IV, , P1, (bb bits), , CN-3, , +, , K, , Encrypt, , C1, (bb bits), , , , K, , PN-2, (bb bits), , PN-1, (bb bits), , PN, (j bits), , +, , +, , +, , Encrypt, , CN-2, (bb bits), , K, , Encrypt, , K, , Encrypt, , CN-1, (bb bits), , select, leftmost, j bits, , CN, (j bits), , (b) Alternative method, , Figure 7.18 Block Cipher Modes for Plaintext not a Multiple of Block Size, , 7.15, , character string into an integer, and vice-versa, in the specified radix. (Hint: Consider, the next-lower and next-higher power of two for each integer.), a. How many bits are exactly required to encode the following integers? (The number shown as an integer’s subscript refers to the radix of that integer.), i. 2 0 4 7 1 0, ii. 2 0 4 8 1 0, iii. 3 2 7 6 7 1 0, iv. 3 2 7 6 8 1 0, v. 3 2 7 6 7 1 6, vi. 3 2 7 6 8 1 6, vii. 5 3 7 F1 6, viii. 2 9 4 3 1 1 0, b. Exactly how many bytes are required to represent the numbers in (a) above?, a. In radix-26, write down the numeral string X for each of the following character, strings, followed by the number of “digits” (i.e., the length of the numeral string), in each case., i. “hex”, ii. “cipher”, iii. “not”, iv. “symbol”
Page 250 :
7.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 7.16, , 7.17, 7.18, , 249, , b. For each case of problem (a), determine the number x = NUM26(X), c. Determine the byte form [x] for each number x computed in problem (b)., d. What is the smallest power of the radix (26) that is greater than each of the numerical strings determined in (b)?, e. Is it related to the length of the numeral string in each case, in problem (a)? If so,, what is this relationship?, Refer to algorithms FF1 and FF2., a. For step 1, for each algorithm, u d : n/2 ; and v d < n - u = . Show that for any, three integers x, y, and n:, if x = : n/2 ; and y = < n - x = , then:, i. Either x = n/2, or x = (n - 1)/2., ii. Either y = n/2, or y = (n + 1)/2., iii. x … y. (Under what condition is x = y?), b. What is the significance of result in the previous sub-problem (iii), in terms of the, lengths u and v of the left and right half-strings, respectively?, In step 3 of Algorithm FF1, what do b and d represent? What is the unit of measurement (bits, bytes, digits, characters) of each of these quantities?, In the inputs to algorithms FF1, FF2, and FF3, why are the specified radix ranges, important? For example, why should radix ∈ [0..28] for Algorithm FF2, or, radix ∈ [2..216] in the case of Algorithm FF3?, , Programming Problems, 7.19, , 7.20, , 7.21, , 7.22, , Create software that can encrypt and decrypt in cipher block chaining mode using one, of the following ciphers: affine modulo 256, Hill modulo 256, S-DES, DES., Test data for S-DES using a binary initialization vector of 1010 1010. A binary plaintext of 0000 0001 0010 0011 encrypted with a binary key of 01111 11101 should give, a binary plaintext of 1111 0100 0000 1011. Decryption should work correspondingly., Create software that can encrypt and decrypt in 4-bit cipher feedback mode using one, of the following ciphers: additive modulo 256, affine modulo 256, S-DES;, or, 8-bit cipher feedback mode using one of the following ciphers: 2 * 2 Hill modulo 256., Test data for S-DES using a binary initialization vector of 1010 1011. A binary plaintext of 0001 0010 0011 0100 encrypted with a binary key of 01111 11101 should give, a binary plaintext of 1110 1100 1111 1010. Decryption should work correspondingly., Create software that can encrypt and decrypt in counter mode using one of the following ciphers: affine modulo 256, Hill modulo 256, S-DES., Test data for S-DES using a counter starting at 0000 0000. A binary plaintext of 0000, 0001 0000 0010 0000 0100 encrypted with a binary key of 01111 11101 should give, a binary plaintext of 0011 1000 0100 1111 0011 0010. Decryption should work correspondingly., Implement a differential cryptanalysis attack on 3-round S-DES.
Page 251 :
CHAPTER, , Random Bit Generation, and Stream Ciphers, 8.1, , Principles of Pseudorandom Number Generation, The Use of Random Numbers, TRNGs, PRNGs, and PRFs, PRNG Requirements, Algorithm Design, , 8.2, , Pseudorandom Number Generators, Linear Congruential Generators, Blum Blum Shub Generator, , 8.3, , Pseudorandom Number Generation Using a Block Cipher, PRNG Using Block Cipher Modes of Operation, ANSI X9.17 PRNG, NIST CTR_DRBG, , 8.4, , Stream Ciphers, , 8.5, , RC4, Initialization of S, Stream Generation, Strength of RC4, , 8.6, , True Random Number Generators, Entropy Sources, Comparison of PRNGs and TRNGs, Conditioning, Health Testing, Intel Digital Random Number Generator, , 8.7, , 250, , Key Terms, Review Questions, and Problems
Page 252 :
RANDOM BIT GENERATION AND STREAM CIPHERS, , 251, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Explain the concepts of randomness and unpredictability with respect to, random numbers., ◆ Understand the differences among true random number generators,, pseudorandom number generators, and pseudorandom functions., ◆ Present an overview of requirements for pseudorandom number generators., ◆ Explain how a block cipher can be used to construct a pseudorandom, number generator., ◆ Present an overview of stream ciphers and RC4., ◆ Explain the significance of skew., , An important cryptographic function is the generation of random bit streams. Random, bits streams are used in a wide variety of contexts, including key generation and, encryption. In essence, there are two fundamentally different strategies for generating, random bits or random numbers. One strategy, which until recently dominated in cryptographic applications, computes bits deterministically using an algorithm. This class of, random bit generators is known as pseudorandom number generators (PRNGs) or, deterministic random bit generators (DRBGs). The other strategy is to produce bits, non-deterministically using some physical source that produces some sort of random, output. This latter class of random bit generators is known as true random number, generators (TRNGs) or non-deterministic random bit generators (NRBGs)., The chapter begins with an analysis of the basic principles of PRNGs. Next, we, look at some common PRNGs, including PRNGs based on the use of a symmetric, block cipher. The chapter then moves on to the topic of symmetric stream ciphers,, which are based on the use of a PRNG. The chapter next examines the most important, stream cipher, RC4., The remainder of the chapter is devoted to TRNGs. We look first at the basic, principles and structure of TRNGs, and then examine a specific product, the Intel, Digital Random Number Generator., Throughout this chapter, reference is made to four important NIST documents:, ■, ■, , ■, , SP 800-90A (Recommendation for Random Number Generation Using, Deterministic Random Bit Generators, January 2012) covers DRNGs., SP 800-90B (Recommendation for the Entropy Sources Used for Random Bit, Generation, August 2012) covers criteria for entropy sources (ES), the devices, from which we get unpredictable randomness and NRNGs., SP 800-90C (Recommendation for Random Bit Generator (RBG), Constructions, August 2012) discusses how to combine the entropy sources in, 90B with the DRNG’s from 90A to provide large quantities of unpredictable, bits for cryptographic applications.
Page 253 :
252, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, ■, , SP 800-22 (A Statistical Test Suite for Random and Pseudorandom Number, Generators for Cryptographic Applications, April 2010) discusses the selection, and testing of NRBGs and DRBGs., , These specifications have heavily influenced the implementation of random bit, generators in industry both in the U.S. and worldwide., , 8.1 PRINCIPLES OF PSEUDORANDOM NUMBER GENERATION, Random numbers play an important role in the use of encryption for various network security applications. In this section, we provide a brief overview of the use, of random numbers in cryptography and network security and then focus on the, principles of pseudorandom number generation., , The Use of Random Numbers, A number of network security algorithms and protocols based on cryptography, make use of random binary numbers. For example,, ■, , ■, , ■, ■, , Key distribution and reciprocal (mutual) authentication schemes, such as, those discussed in Chapters 14 and 15. In such schemes, two communicating, parties cooperate by exchanging messages to distribute keys and/or authenticate each other. In many cases, nonces are used for handshaking to prevent, replay attacks. The use of random numbers for the nonces frustrates an opponent’s efforts to determine or guess the nonce, in order to repeat an obsolete, transaction., Session key generation. We will see a number of protocols in this book where a, secret key for symmetric encryption is generated for use for a particular transaction (or session) and is valid for a short period of time. This key is generally, called a session key., Generation of keys for the RSA public-key encryption algorithm (described, in Chapter 9)., Generation of a bit stream for symmetric stream encryption (described in this, chapter)., , These applications give rise to two distinct and not necessarily compatible, requirements for a sequence of random numbers: randomness and unpredictability., RANDOMNESS Traditionally, the concern in the generation of a sequence of allegedly random numbers has been that the sequence of numbers be random in some, well-defined statistical sense. The following two criteria are used to validate that a, sequence of numbers is random:, ■, , ■, , Uniform distribution: The distribution of bits in the sequence should be, uniform; that is, the frequency of occurrence of ones and zeros should be, approximately equal., Independence: No one subsequence in the sequence can be inferred from the, others.
Page 254 :
8.1 / PRINCIPLES OF PSEUDORANDOM NUMBER GENERATION, , 253, , Although there are well-defined tests for determining that a sequence of bits, matches a particular distribution, such as the uniform distribution, there is no such, test to “prove” independence. Rather, a number of tests can be applied to demonstrate if a sequence does not exhibit independence. The general strategy is to apply, a number of such tests until the confidence that independence exists is sufficiently, strong. That is, if each of a number of tests fails to show that a sequence of bits is, not independent, then we can have a high level of confidence that the sequence is in, fact independent., In the context of our discussion, the use of a sequence of numbers that appear, statistically random often occurs in the design of algorithms related to cryptography., For example, a fundamental requirement of the RSA public-key encryption scheme, discussed in Chapter 9 is the ability to generate prime numbers. In general, it is, difficult to determine if a given large number N is prime. A brute-force approach, would be to divide N by every odd integer less than 2N. If N is on the order, say,, of 10150, which is a not uncommon occurrence in public-key cryptography, such a, brute-force approach is beyond the reach of human analysts and their computers., However, a number of effective algorithms exist that test the primality of a number by using a sequence of randomly chosen integers as input to relatively simple, computations. If the sequence is sufficiently long (but far, far less than 210150), the, primality of a number can be determined with near certainty. This type of approach,, known as randomization, crops up frequently in the design of algorithms. In essence, if a problem is too hard or time-consuming to solve exactly, a simpler, shorter, approach based on randomization is used to provide an answer with any desired, level of confidence., UNPREDICTABILITY In applications such as reciprocal authentication, session key, generation, and stream ciphers, the requirement is not just that the sequence of, numbers be statistically random but that the successive members of the sequence, are unpredictable. With “true” random sequences, each number is statistically independent of other numbers in the sequence and therefore unpredictable. Although, true random numbers are used in some applications, they have their limitations,, such as inefficiency, as is discussed shortly. Thus, it is more common to implement algorithms that generate sequences of numbers that appear to be random. In, this latter case, care must be taken that an opponent not be able to predict future, elements of the sequence on the basis of earlier elements., , TRNGs, PRNGs, and PRFs, Cryptographic applications typically make use of algorithmic techniques for random number generation. These algorithms are deterministic and therefore produce, sequences of numbers that are not statistically random. However, if the algorithm is, good, the resulting sequences will pass many tests of randomness. Such numbers are, referred to as pseudorandom numbers., You may be somewhat uneasy about the concept of using numbers generated, by a deterministic algorithm as if they were random numbers. Despite what might be, called philosophical objections to such a practice, it generally works. That is, under, most circumstances, pseudorandom numbers will perform as well as if they were, random for a given use. The phrase “as well as” is unfortunately subjective, but the, , Hiva-Network.Com
Page 255 :
254, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, Contextspecific, Seed values, , Source of, true, randomness, , Seed, , Conversion, to binary, , Deterministic, algorithm, , Deterministic, algorithm, , Random, bit stream, , Pseudorandom, bit stream, , Pseudorandom, value, , (a) TRNG, , (b) PRNG, , (c) PRF, , TRNG = true random number generator, PRNG = pseudorandom number generator, PRF = pseudorandom function, , Figure 8.1, , Random and Pseudorandom Number Generators, , use of pseudorandom numbers is widely accepted. The same principle applies in, statistical applications, in which a statistician takes a sample of a population and, assumes that the results will be approximately the same as if the whole population, were measured., Figure 8.1 contrasts a true random number generator (TRNG) with two forms, of pseudorandom number generators. A TRNG takes as input a source that is, effectively random; the source is often referred to as an entropy source. We discuss, such sources in Section 8.6. In essence, the entropy source is drawn from the physical environment of the computer and could include things such as keystroke timing, patterns, disk electrical activity, mouse movements, and instantaneous values of the, system clock. The source, or combination of sources, serve as input to an algorithm, that produces random binary output. The TRNG may simply involve conversion of, an analog source to a binary output. The TRNG may involve additional processing, to overcome any bias in the source; this is discussed in Section 8.6., In contrast, a PRNG takes as input a fixed value, called the seed, and produces, a sequence of output bits using a deterministic algorithm. Quite often, the seed is, generated by a TRNG. Typically, as shown, there is some feedback path by which, some of the results of the algorithm are fed back as input as additional output bits, are produced. The important thing to note is that the output bit stream is determined solely by the input value or values, so that an adversary who knows the algorithm and the seed can reproduce the entire bit stream., Figure 8.1 shows two different forms of PRNGs, based on application., ■, , Pseudorandom number generator: An algorithm that is used to produce an, open-ended sequence of bits is referred to as a PRNG. A common application, for an open-ended sequence of bits is as input to a symmetric stream cipher,, as discussed in Section 8.4. Also, see Figure 4.1a.
Page 256 :
8.1 / PRINCIPLES OF PSEUDORANDOM NUMBER GENERATION, ■, , 255, , Pseudorandom function (PRF): A PRF is used to produce a pseudorandom, string of bits of some fixed length. Examples are symmetric encryption keys, and nonces. Typically, the PRF takes as input a seed plus some context specific, values, such as a user ID or an application ID. A number of examples of PRFs, will be seen throughout this book, notably in Chapters 17 and 18., , Other than the number of bits produced, there is no difference between a, PRNG and a PRF. The same algorithms can be used in both applications. Both, require a seed and both must exhibit randomness and unpredictability. Further,, a PRNG application may also employ context-specific input. In what follows, we, make no distinction between these two applications., , PRNG Requirements, When a PRNG or PRF is used for a cryptographic application, then the basic, requirement is that an adversary who does not know the seed is unable to determine, the pseudorandom string. For example, if the pseudorandom bit stream is used in, a stream cipher, then knowledge of the pseudorandom bit stream would enable the, adversary to recover the plaintext from the ciphertext. Similarly, we wish to protect the output value of a PRF. In this latter case, consider the following scenario., A 128-bit seed, together with some context-specific values, are used to generate a, 128-bit secret key that is subsequently used for symmetric encryption. Under normal circumstances, a 128-bit key is safe from a brute-force attack. However, if the, PRF does not generate effectively random 128-bit output values, it may be possible, for an adversary to narrow the possibilities and successfully use a brute force attack., This general requirement for secrecy of the output of a PRNG or PRF leads, to specific requirements in the areas of randomness, unpredictability, and the characteristics of the seed. We now look at these in turn., RANDOMNESS In terms of randomness, the requirement for a PRNG is that the generated bit stream appear random even though it is deterministic. There is no single, test that can determine if a PRNG generates numbers that have the characteristic, of randomness. The best that can be done is to apply a sequence of tests to the, PRNG. If the PRNG exhibits randomness on the basis of multiple tests, then it can, be assumed to satisfy the randomness requirement. NIST SP 800-22 specifies that, the tests should seek to establish the following three characteristics., ■, , ■, , ■, , Uniformity: At any point in the generation of a sequence of random or pseudorandom bits, the occurrence of a zero or one is equally likely, that is, the, probability of each is exactly 1/2. The expected number of zeros (or ones) is, n/2, where n = the sequence length., Scalability: Any test applicable to a sequence can also be applied to subsequences extracted at random. If a sequence is random, then any such extracted, subsequence should also be random. Hence, any extracted subsequence should, pass any test for randomness., Consistency: The behavior of a generator must be consistent across starting, values (seeds). It is inadequate to test a PRNG based on the output from, a single seed or a TRNG on the basis of an output produced from a single, physical output.
Page 257 :
256, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , SP 800-22 lists 15 separate tests of randomness. An understanding of these, tests requires a basic knowledge of statistical analysis, so we don’t attempt a technical description here. Instead, to give some flavor for the tests, we list three of the, tests and the purpose of each test, as follows., ■, , ■, , ■, , Frequency test: This is the most basic test and must be included in any test, suite. The purpose of this test is to determine whether the number of ones and, zeros in a sequence is approximately the same as would be expected for a truly, random sequence., Runs test: The focus of this test is the total number of runs in the sequence,, where a run is an uninterrupted sequence of identical bits bounded before, and after with a bit of the opposite value. The purpose of the runs test is to, determine whether the number of runs of ones and zeros of various lengths is, as expected for a random sequence., Maurer’s universal statistical test: The focus of this test is the number of, bits between matching patterns (a measure that is related to the length of a, compressed sequence). The purpose of the test is to detect whether or not, the sequence can be significantly compressed without loss of information., A significantly compressible sequence is considered to be non-random., , UNPREDICTABILITY A stream of pseudorandom numbers should exhibit two forms, of unpredictability:, ■, , ■, , Forward unpredictability: If the seed is unknown, the next output bit in the, sequence should be unpredictable in spite of any knowledge of previous bits, in the sequence., Backward unpredictability: It should also not be feasible to determine the, seed from knowledge of any generated values. No correlation between a seed, and any value generated from that seed should be evident; each element of the, sequence should appear to be the outcome of an independent random event, whose probability is 1/2., , The same set of tests for randomness also provide a test of unpredictability. If, the generated bit stream appears random, then it is not possible to predict some bit, or bit sequence from knowledge of any previous bits. Similarly, if the bit sequence, appears random, then there is no feasible way to deduce the seed based on the bit, sequence. That is, a random sequence will have no correlation with a fixed value, (the seed)., SEED REQUIREMENTS For cryptographic applications, the seed that serves as input to, the PRNG must be secure. Because the PRNG is a deterministic algorithm, if the, adversary can deduce the seed, then the output can also be determined. Therefore,, the seed must be unpredictable. In fact, the seed itself must be a random or pseudorandom number., Typically, the seed is generated by a TRNG, as shown in Figure 8.2. This is, the scheme recommended by SP 800-90A. The reader may wonder, if a TRNG is, available, why it is necessary to use a PRNG. If the application is a stream cipher,, then a TRNG is not practical. The sender would need to generate a keystream of
Page 258 :
8.1 / PRINCIPLES OF PSEUDORANDOM NUMBER GENERATION, , 257, , Entropy, source, , True random, number generator, (TRNG), Seed, Pseudorandom, number generator, (PRNG), , Pseudorandom, bit stream, , Figure 8.2, , Generation of Seed Input to PRNG, , bits as long as the plaintext and then transmit the keystream and the ciphertext, securely to the receiver. If a PRNG is used, the sender need only find a way to, deliver the stream cipher key, which is typically 54 or 128 bits, to the receiver in a, secure fashion., Even in the case of a PRF application, in which only a limited number of bits, is generated, it is generally desirable to use a TRNG to provide the seed to the, PRF and use the PRF output rather than use the TRNG directly. As is explained in, Section 8.6, a TRNG may produce a binary string with some bias. The PRF would, have the effect of conditioning the output of the TRNG so as to eliminate that bias., Finally, the mechanism used to generate true random numbers may not be, able to generate bits at a rate sufficient to keep up with the application requiring, the random bits., , Algorithm Design, Cryptographic PRNGs have been the subject of much research over the years,, and a wide variety of algorithms have been developed. These fall roughly into two, categories., ■, , ■, , Purpose-built algorithms: These are algorithms designed specifically and, solely for the purpose of generating pseudorandom bit streams. Some of these, algorithms are used for a variety of PRNG applications; several of these are, described in the next section. Others are designed specifically for use in a, stream cipher. The most important example of the latter is RC4, described in, Section 8.5., Algorithms based on existing cryptographic algorithms: Cryptographic, algorithms have the effect of randomizing input data. Indeed, this is a requirement of such algorithms. For example, if a symmetric block cipher produced, ciphertext that had certain regular patterns in it, it would aid in the process of
Page 259 :
258, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , cryptanalysis. Thus, cryptographic algorithms can serve as the core of PRNGs., Three broad categories of cryptographic algorithms are commonly used to, create PRNGs:, –Symmetric block ciphers: This approach is discussed in Section 8.3., –Asymmetric ciphers: The number theoretic concepts used for an asymmetric cipher can also be adapted for a PRNG; this approach is examined in, Chapter 10., –Hash functions and message authentication codes: This approach is examined in Chapter 12., Any of these approaches can yield a cryptographically strong PRNG., A purpose-built algorithm may be provided by an operating system for general use., For applications that already use certain cryptographic algorithms for encryption or, authentication, it makes sense to reuse the same code for the PRNG. Thus, all of, these approaches are in common use., , 8.2 PSEUDORANDOM NUMBER GENERATORS, In this section, we look at two types of algorithms for PRNGs., , Linear Congruential Generators, A widely used technique for pseudorandom number generation is an algorithm first, proposed by Lehmer [LEHM51], which is known as the linear congruential method., The algorithm is parameterized with four numbers, as follows:, m, a, c, X0, , the modulus, the multiplier, the increment, the starting value, or seed, , m 7 0, 0 6 a 6 m, 0 … c 6 m, 0 … X0 6 m, , The sequence of random numbers {Xn} is obtained via the following iterative, equation:, Xn + 1 = (aXn + c) mod m, If m, a, c, and X0 are integers, then this technique will produce a sequence of integers with each integer in the range 0 … Xn 6 m., The selection of values for a, c, and m is critical in developing a good random number generator. For example, consider a = c = 1. The sequence produced, is obviously not satisfactory. Now consider the values a = 7, c = 0, m = 32, and, X0 = 1. This generates the sequence {7, 17, 23, 1, 7, etc.}, which is also clearly, unsatisfactory. Of the 32 possible values, only four are used; thus, the sequence, is said to have a period of 4. If, instead, we change the value of a to 5, then the, sequence is {5, 25, 29, 17, 21, 9, 13, 1, 5, etc. }, which increases the period to 8., We would like m to be very large, so that there is the potential for producing, a long series of distinct random numbers. A common criterion is that m be nearly
Page 260 :
8.2 / PSEUDORANDOM NUMBER GENERATORS, , 259, , equal to the maximum representable nonnegative integer for a given computer., Thus, a value of m near to or equal to 231 is typically chosen., [PARK88] proposes three tests to be used in evaluating a random number, generator:, T1:, T2:, T3:, , The function should be a full-period generating function. That is, the function, should generate all the numbers from 0 through m - 1 before repeating., The generated sequence should appear random., The function should implement efficiently with 32-bit arithmetic., , With appropriate values of a, c, and m, these three tests can be passed. With, respect to T1, it can be shown that if m is prime and c = 0, then for certain values, of a the period of the generating function is m - 1, with only the value 0 missing., For 32-bit arithmetic, a convenient prime value of m is 231 - 1. Thus, the generating, function becomes, Xn + 1 = (aXn) mod (231 - 1), Of the more than 2 billion possible choices for a, only a handful of multipliers, pass all three tests. One such value is a = 75 = 16807, which was originally selected, for use in the IBM 360 family of computers [LEWI69]. This generator is widely, used and has been subjected to a more thorough testing than any other PRNG. It is, frequently recommended for statistical and simulation work (e.g., [JAIN91])., The strength of the linear congruential algorithm is that if the multiplier and, modulus are properly chosen, the resulting sequence of numbers will be statistically, indistinguishable from a sequence drawn at random (but without replacement) from, the set 1, 2, c , m - 1. But there is nothing random at all about the algorithm, apart, from the choice of the initial value X0. Once that value is chosen, the remaining numbers in the sequence follow deterministically. This has implications for cryptanalysis., If an opponent knows that the linear congruential algorithm is being used and, if the parameters are known (e.g., a = 75, c = 0, m = 231 - 1), then once a single, number is discovered, all subsequent numbers are known. Even if the opponent, knows only that a linear congruential algorithm is being used, knowledge of a small, part of the sequence is sufficient to determine the parameters of the algorithm., Suppose that the opponent is able to determine values for X0, X1, X2, and X3. Then, X1 = (aX0 + c) mod m, X2 = (aX1 + c) mod m, X3 = (aX2 + c) mod m, These equations can be solved for a, c, and m., Thus, although it is nice to be able to use a good PRNG, it is desirable to make, the actual sequence used nonreproducible, so that knowledge of part of the sequence on the part of an opponent is insufficient to determine future elements of the, sequence. This goal can be achieved in a number of ways. For example, [BRIG79], suggests using an internal system clock to modify the random number stream. One, way to use the clock would be to restart the sequence after every N numbers using, the current clock value (mod m) as the new seed. Another way would be simply to, add the current clock value to each random number (mod m).
Page 261 :
260, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , Blum Blum Shub Generator, A popular approach to generating secure pseudorandom numbers is known as, the Blum Blum Shub (BBS) generator (see Figure 8.3), named for its developers, [BLUM86]. It has perhaps the strongest public proof of its cryptographic strength, of any purpose-built algorithm. The procedure is as follows. First, choose two large, prime numbers, p and q, that both have a remainder of 3 when divided by 4. That is,, p K q K 3(mod 4), This notation, explained more fully in Chapter 4, simply means that (p mod 4) =, (q mod 4) = 3. For example, the prime numbers 7 and 11 satisfy 7 K 11 K 3(mod 4)., Let n = p * q. Next, choose a random number s, such that s is relatively prime to n;, this is equivalent to saying that neither p nor q is a factor of s. Then the BBS generator produces a sequence of bits B i according to the following algorithm:, X0, for i, Xi, Bi, , =, =, =, =, , s2 mod n, 1 to ∞, (Xi−1)2 mod n, Xi mod 2, , Thus, the least significant bit is taken at each iteration. Table 8.1 shows an example, of BBS operation. Here, n = 192649 = 383 * 503, and the seed s = 101355., The BBS is referred to as a cryptographically secure pseudorandom bit, generator (CSPRBG). A CSPRBG is defined as one that passes the next-bit test,, which, in turn, is defined as follows [MENE97]: A pseudorandom bit generator is, said to pass the next-bit test if there is not a polynomial-time algorithm1 that, on, input of the first k bits of an output sequence, can predict the (k + 1)st bit with, probability significantly greater than 1/2. In other words, given the first k bits of the, Initialize, with seed s, , Generate, x2 mod n, , Select least, significant bit, , [0, 1], Figure 8.3, 1, , Blum Blum Shub Block Diagram, , A polynomial-time algorithm of order k is one whose running time is bounded by a polynomial of order k.
Page 262 :
8.3 / PSEUDORANDOM NUMBER GENERATION USING A BLOCK CIPHER, Table 8.1, , 261, , Example Operation of BBS Generator, , i, , Xi, , 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, , 20749, 143135, 177671, 97048, 89992, 174051, 80649, 45663, 69442, 186894, 177046, , Bi, 1, 1, 0, 0, 1, 1, 1, 0, 0, 0, , i, , Xi, , Bi, , 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, , 137922, 123175, 8630, 114386, 14863, 133015, 106065, 45870, 137171, 48060, , 0, 1, 0, 0, 1, 1, 1, 0, 1, 0, , sequence, there is not a practical algorithm that can even allow you to state that the, next bit will be 1 (or 0) with probability greater than 1/2. For all practical purposes,, the sequence is unpredictable. The security of BBS is based on the difficulty of, factoring n. That is, given n, we need to determine its two prime factors p and q., , 8.3 PSEUDORANDOM NUMBER GENERATION USING, A BLOCK CIPHER, A popular approach to PRNG construction is to use a symmetric block cipher as, the heart of the PRNG mechanism. For any block of plaintext, a symmetric block, cipher produces an output block that is apparently random. That is, there are no, patterns or regularities in the ciphertext that provide information that can be used, to deduce the plaintext. Thus, a symmetric block cipher is a good candidate for, building a pseudorandom number generator., If an established, standardized block cipher is used, such as DES or AES, then, the security characteristics of the PRNG can be established. Further, many applications already make use of DES or AES, so the inclusion of the block cipher as part, of the PRNG algorithm is straightforward., , PRNG Using Block Cipher Modes of Operation, Two approaches that use a block cipher to build a PNRG have gained widespread, acceptance: the CTR mode and the OFB mode. The CTR mode is recommended in, NIST SP 800-90A, in the ANSI standard X9.82 (Random Number Generation), and, in RFC 4086 (Randomness Requirements for Security, June 2005). The OFB mode is, recommended in X9.82 and RFC 4086., Figure 8.4 illustrates the two methods. In each case, the seed consists of two, parts: the encryption key value and a value V that will be updated after each block, of pseudorandom numbers is generated. Thus, for AES-128, the seed consists of a, 128-bit key and a 128-bit V value. In the CTR case, the value of V is incremented
Page 263 :
262, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, 1, , +, , V, , K, , Encrypt, , V, , K, , Encrypt, , Pseudorandom bits, , Pseudorandom bits, , (a) CTR mode, , (b) OFB mode, , Figure 8.4, , PRNG Mechanisms Based on Block Ciphers, , by 1 after each encryption. In the case of OFB, the value of V is updated to equal the, value of the preceding PRNG block. In both cases, pseudorandom bits are produced, one block at a time (e.g., for AES, PRNG bits are generated 128 bits at a time)., The CTR algorithm for PRNG, called CTR_DRBG, can be summarized, as follows., while (len (temp) < requested_number_of_bits) do, V = (V + 1) mod 2128, output_block = E(Key, V), temp = temp || output_block, The OFB algorithm can be summarized as follows., while (len (temp) < requested_number_of_bits) do, V = E(Key, V), temp = temp || V, To get some idea of the performance of these two PRNGs, consider the following short experiment. A random bit sequence of 256 bits was obtained from, random.org, which uses three radios tuned between stations to pick up atmospheric, noise. These 256 bits form the seed, allocated as, Key:, , cfb0ef3108d49cc4562d5810b0a9af60, , V:, , 4c89af496176b728ed1e2ea8ba27f5a4, , The total number of one bits in the 256-bit seed is 124, or a fraction of 0.48,, which is reassuringly close to the ideal of 0.5., For the OFB PRNG, Table 8.2 shows the first eight output blocks (1024 bits), with two rough measures of security. The second column shows the fraction of one, bits in each 128-bit block. This corresponds to one of the NIST tests. The results, indicate that the output is split roughly equally between zero and one bits. The, third column shows the fraction of bits that match between adjacent blocks. If this, , Hiva-Network.Com
Page 264 :
8.3 / PSEUDORANDOM NUMBER GENERATION USING A BLOCK CIPHER, Table 8.2, , Example Results for PRNG Using OFB, , Output Block, , Fraction of, One Bits, , Fraction of Bits, that Match with, Preceding Block, , 1786f4c7ff6e291dbdfdd90ec3453176, 5e17b22b14677a4d66890f87565eae64, fd18284ac82251dfb3aa62c326cd46cc, c8e545198a758ef5dd86b41946389bd5, fe7bae0e23019542962e2c52d215a2e3, 14fdf5ec99469598ae0379472803accd, 6aeca972e5a3ef17bd1a1b775fc8b929, f7e97badf359d128f00d9b4ae323db64, , 0.57, 0.51, 0.47, 0.50, 0.47, 0.49, 0.57, 0.55, , —, 0.52, 0.54, 0.44, 0.48, 0.52, 0.48, 0.45, , Output Block, , Fraction of, One Bits, , Fraction of Bits, that Match with, Preceding Block, , 1786f4c7ff6e291dbdfdd90ec3453176, , 0.57, , —, , 60809669a3e092a01b463472fdcae420, , 0.41, , 0.41, , d4e6e170b46b0573eedf88ee39bff33d, , 0.59, , 0.45, , 5f8fcfc5deca18ea246785d7fadc76f8, , 0.59, , 0.52, , 90e63ed27bb07868c753545bdd57ee28, , 0.53, , 0.52, , 0125856fdf4a17f747c7833695c52235, f4be2d179b0f2548fd748c8fc7c81990, 1151fc48f90eebac658a3911515c3c66, , 0.50, 0.51, 0.47, , 0.47, 0.48, 0.45, , Table 8.3, , 263, , Example Results for PRNG Using CTR, , number differs substantially from 0.5, that suggests a correlation between blocks,, which could be a security weakness. The results suggest no correlation., Table 8.3 shows the results using the same key and V values for CTR mode., Again, the results are favorable., , ANSI X9.17 PRNG, One of the strongest (cryptographically speaking) PRNGs is specified in ANSI, X9.17. A number of applications employ this technique, including financial security, applications and PGP (the latter described in Chapter 19)., Figure 8.5 illustrates the algorithm, which makes use of triple DES for encryption. The ingredients are as follows., ■, , ■, , Input: Two pseudorandom inputs drive the generator. One is a 64-bit representation of the current date and time, which is updated on each number generation. The other is a 64-bit seed value; this is initialized to some arbitrary value, and is updated during the generation process., Keys: The generator makes use of three triple DES encryption modules. All, three make use of the same pair of 56-bit keys, which must be kept secret and, are used only for pseudorandom number generation.
Page 265 :
264, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, K1, K2, , DTi, , EDE, , EDE, , Vi, , Vi+1, , EDE, , Ri, , Figure 8.5 ANSI X9.17 Pseudorandom Number Generator, ■, , Output: The output consists of a 64-bit pseudorandom number and a 64-bit, seed value., Let us define the following quantities., , DTi, Vi, Ri, K1, K2, , Date/time value at the beginning of ith generation stage, Seed value at the beginning of ith generation stage, Pseudorandom number produced by the ith generation stage, DES keys used for each stage, , Then, Ri = EDE([K1, K2], [Vi ⊕ EDE([K1, K2], DTi)]), Vi + 1 = EDE([K1, K2], [Ri ⊕ EDE([K1, K2], DTi)]), where EDE([K1, K2], X) refers to the sequence encrypt-decrypt-encrypt using twokey triple DES to encrypt X., Several factors contribute to the cryptographic strength of this method. The, technique involves a 112-bit key and three EDE encryptions for a total of nine DES, encryptions. The scheme is driven by two independent inputs, the date and time, value, and a seed produced by the generator that is distinct from the pseudorandom, number produced by the generator. Thus, the amount of material that must be compromised by an opponent appears to be overwhelming. Even if a pseudorandom, number Ri were compromised, it would be impossible to deduce the Vi + 1 from the, Ri, because an additional EDE operation is used to produce the Vi + 1., , NIST CTR_DRBG, We now look more closely at the details of the PRNG defined in NIST SP 800-90A, based on the CTR mode of operation. The PRNG is referred to as CTRDRBG, (counter mode–deterministic random bit generator). CTR_DRBG is widely implemented and is part of the hardware random number generator implemented on all, recent Intel processor chips (discussed in Section 8.6).
Page 266 :
8.3 / PSEUDORANDOM NUMBER GENERATION USING A BLOCK CIPHER, , 265, , The DRBG assumes that an entropy source is available to provide random, bits. Typically, the entropy source will be a TRNG based on some physical source., Other sources are possible if they meet the required entropy measure of the application. Entropy is an information theoretic concept that measures unpredictability,, or randomness; see Appendix F for details. The encryption algorithm used in the, DRBG may be 3DES with three keys or AES with a key size of 128, 192, or 256 bits., Four parameters are associated with the algorithm:, ■, ■, ■, , ■, , Output block length (outlen): Length of the output block of the encryption, algorithm., Key length (keylen): Length of the encryption key., Seed length (seedlen): The seed is a string of bits that is used as input to a, DRBG mechanism. The seed will determine a portion of the internal state of, the DRBG, and its entropy must be sufficient to support the security strength, of the DRBG. seedlen = outlen + keylen., Reseed interval (reseed_interval): Length of the encryption key. It is the maximum number of output blocks generated before updating the algorithm with, a new seed., Table 8.4 lists the values specified in SP 800-90A for these parameters., , INITIALIZE Figure 8.6 shows the two principal functions that comprise CTR_DRBG., We first consider how CTR_DRBG is initialized, using the initialize and update, function (Figure 8.6a). Recall that the CTR block cipher mode requires both an, encryption key K and an initial counter value, referred to in SP 800-90A as the, counter V. The combination of K and V is referred to as the seed. To start the, DRGB operation, initial values for K and V are needed, and can be chosen arbitrarily. As an example, the Intel Digital Random Number Generator, discussed in, Section 8.6, uses the values K = 0 and V = 0. These values are used as parameters for the CTR mode of operation to produce at least seedlen bits. In addition,, exactly seedlen bits must be supplied from what is referred to as an entropy source., Typically, the entropy source would be some form of TRNG., With these inputs, the CTR mode of encryption is iterated to produce a, sequence of output blocks, with V incremented by 1 after each encryption. The process continues until at least seedlen bits have been generated. The leftmost seedlen, bits of output are then XORed with the seedlen entropy bits to produce a new seed., In turn, the leftmost keylen bits of the seed form the new key and the rightmost, outlen bits of the seed form the new counter value V., Table 8.4, , CTR_DRBG Parameters, , outlen, keylen, seedlen, reseed_interval, , 3DES, , AES-128, , AES-192, , AES-256, , 64, 168, 232, , 128, 128, 256, , 128, 192, 320, , 128, 256, 384, , … 232, , … 248, , … 248, , … 248
Page 267 :
266, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, 1, V, , 1st, time, , Iterate, , +, , Key, , Encrypt, , B0, , Bi, , Entropy, source, , V, , Key, , (a) Initialize and update function, , 1, , Iterate, , +, Key, , V, , Encrypt, , (b) Generate function, , Figure 8.6, , CTR_DRBG Functions, , GENERATE Once values of Key and V are obtained, the DRBG enters the generate, phase and is able to generate pseudorandom bits, one output block at a time, (Figure 8.6b). The encryption function is iterated to generate the number of pseudorandom bits desired. Each iteration uses the same encryption key. The counter, value V is incremented by 1 for each iteration., UPDATE To enhance security, the number of bits generated by any PRNG should be, limited. CTR_DRGB uses the parameter reseed_interval to set that limit. During the, generate phase, a reseed counter is initialized to 1 and then incremented with each
Page 268 :
8.4 / STREAM CIPHERS, , 267, , iteration (each production of an output block). When the reseed counter reaches, reseed_interval, the update function is invoked (Figure 8.6a). The update function, is the same as the initialize function. In the update case, the Key and V values last, used by the generate function serve as the input parameters to the update function., The update function takes seedlen new bits from an entropy source and produces a, new seed (Key, V). The generate function can then resume production of pseudorandom bits. Note that the result of the update function is to change both the Key, and V values used by the generate function., , 8.4 STREAM CIPHERS, A typical stream cipher encrypts plaintext one byte at a time, although a stream, cipher may be designed to operate on one bit at a time or on units larger than a byte, at a time. Figure 8.7 is a representative diagram of stream cipher structure. In this, structure, a key is input to a pseudorandom bit generator that produces a stream, of 8-bit numbers that are apparently random. The output of the generator, called, a keystream, is combined one byte at a time with the plaintext stream using the, bitwise exclusive-OR (XOR) operation. For example, if the next byte generated by, the generator is 01101100 and the next plaintext byte is 11001100, then the resulting, ciphertext byte is, 11001100 plaintext, ⊕ 01101100 key stream, , 10100000 ciphertext, Decryption requires the use of the same pseudorandom sequence:, 10100000 ciphertext, ⊕ 01101100 key stream, , 11001100 plaintext, Key, K, , Key, K, , Pseudorandom byte, generator, (key stream generator), , Pseudorandom byte, generator, (key stream generator), , k, , k, Plaintext, byte stream, M, , ENCRYPTION, , Figure 8.7 Stream Cipher Diagram, , Ciphertext, byte stream, C, , DECRYPTION, , Plaintext, byte stream, M
Page 269 :
268, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , The stream cipher is similar to the one-time pad discussed in Chapter 3. The, difference is that a one-time pad uses a genuine random number stream, whereas a, stream cipher uses a pseudorandom number stream., [KUMA97] lists the following important design considerations for a stream cipher., 1. The encryption sequence should have a large period. A pseudorandom number generator uses a function that produces a deterministic stream of bits that, eventually repeats. The longer the period of repeat the more difficult it will be, to do cryptanalysis. This is essentially the same consideration that was discussed, with reference to the Vigenère cipher, namely that the longer the keyword, the more difficult the cryptanalysis., 2. The keystream should approximate the properties of a true random number, stream as close as possible. For example, there should be an approximately, equal number of 1s and 0s. If the keystream is treated as a stream of bytes,, then all of the 256 possible byte values should appear approximately equally, often. The more random-appearing the keystream is, the more randomized the, ciphertext is, making cryptanalysis more difficult., 3. Note from Figure 8.7 that the output of the pseudorandom number generator is conditioned on the value of the input key. To guard against brute-force, attacks, the key needs to be sufficiently long. The same considerations that, apply to block ciphers are valid here. Thus, with current technology, a key, length of at least 128 bits is desirable., With a properly designed pseudorandom number generator, a stream cipher, can be as secure as a block cipher of comparable key length. A potential advantage, of a stream cipher is that stream ciphers that do not use block ciphers as a building, block are typically faster and use far less code than do block ciphers. The example, in this chapter, RC4, can be implemented in just a few lines of code. In recent years,, this advantage has diminished with the introduction of AES, which is quite efficient, in software. Furthermore, hardware acceleration techniques are now available for, AES. For example, the Intel AES Instruction Set has machine instructions for one, round of encryption and decryption and key generation. Using the hardware instructions results in speedups of about an order of magnitude compared to pure, software implementations [XU10]., One advantage of a block cipher is that you can reuse keys. In contrast, if two, plaintexts are encrypted with the same key using a stream cipher, then cryptanalysis, is often quite simple [DAWS96]. If the two ciphertext streams are XORed together,, the result is the XOR of the original plaintexts. If the plaintexts are text strings,, credit card numbers, or other byte streams with known properties, then cryptanalysis may be successful., For applications that require encryption/decryption of a stream of data, such as, over a data communications channel or a browser/Web link, a stream cipher might, be the better alternative. For applications that deal with blocks of data, such as file, transfer, email, and database, block ciphers may be more appropriate. However,, either type of cipher can be used in virtually any application., A stream cipher can be constructed with any cryptographically strong PRNG,, such as the ones discussed in Sections 8.2 and 8.3. In the next section, we look at a, stream cipher that uses a PRNG designed specifically for the stream cipher.
Page 270 :
8.5 / RC4, , 269, , 8.5 RC4, RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a, variable key size stream cipher with byte-oriented operations. The algorithm is, based on the use of a random permutation. Analysis shows that the period of the, cipher is overwhelmingly likely to be greater than 10100 [ROBS95a]. Eight to sixteen, machine operations are required per output byte, and the cipher can be expected, to run very quickly in software. RC4 is used in the WiFi Protected Access (WPA), protocol that are part of the IEEE 802.11 wireless LAN standard. It is optional for, use in Secure Shell (SSH) and Kerberos. RC4 was kept as a trade secret by RSA, Security. In September 1994, the RC4 algorithm was anonymously posted on the, Internet on the Cypherpunks anonymous remailers list., The RC4 algorithm is remarkably simple and quite easy to explain., A variable-length key of from 1 to 256 bytes (8 to 2048 bits) is used to initialize a, 256-byte state vector S, with elements S[0],S[1], . . . ,S[255]. At all times, S contains, a permutation of all 8-bit numbers from 0 through 255. For encryption and decryption, a byte k (see Figure 8.7) is generated from S by selecting one of the 255 entries, in a systematic fashion. As each value of k is generated, the entries in S are once, again permuted., , Initialization of S, To begin, the entries of S are set equal to the values from 0 through 255 in ascending, order; that is, S[0] = 0, S[1] = 1, c , S[255] = 255. A temporary vector, T, is also, created. If the length of the key K is 256 bytes, then K is transferred to T. Otherwise,, for a key of length keylen bytes, the first keylen elements of T are copied from K,, and then K is repeated as many times as necessary to fill out T. These preliminary, operations can be summarized as, /* Initialization */, for i = 0 to 255 do, S[i] = i;, T[i] = K[i mod keylen];, Next we use T to produce the initial permutation of S. This involves starting, with S[0] and going through to S[255], and for each S[i], swapping S[i] with another, byte in S according to a scheme dictated by T[i]:, /* Initial Permutation of S */, j = 0;, for i = 0 to 255 do, j = (j + S[i] + T[i]) mod 256;, Swap (S[i], S[j]);, Because the only operation on S is a swap, the only effect is a permutation., S still contains all the numbers from 0 through 255.
Page 271 :
270, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , Stream Generation, Once the S vector is initialized, the input key is no longer used. Stream generation, involves cycling through all the elements of S[i], and for each S[i], swapping S[i], with another byte in S according to a scheme dictated by the current configuration, of S. After S[255] is reached, the process continues, starting over again at S[0]:, /* Stream Generation */, i, j = 0;, while (true), i = (i + 1) mod 256;, j = (j + S[i]) mod 256;, Swap (S[i], S[j]);, t = (S[i] + S[j]) mod 256;, k = S[t];, To encrypt, XOR the value k with the next byte of plaintext. To decrypt, XOR, the value k with the next byte of ciphertext., Figure 8.8 illustrates the RC4 logic., , S, , 0, , 1, , 2, , 3, , 4, , 253 254 255, , Keylen, , K, , T, (a) Initial state of S and T, , T, , T[i], j = j + S[i] + T[i], , S, , S[ i], , S[ j ], , i, , Swap, (b) Initial permutation of S, j = j + S[i], , S, , S[ i], i, , S[ j ], , S[ t], , Swap, t = S[i] + S[j], k, (c) Stream generation, , Figure 8.8 RC4
Page 272 :
8.6 / TRUE RANDOM NUMBER GENERATORS, , 271, , Strength of RC4, A number of papers have been published analyzing methods of attacking RC4 (e.g.,, [KNUD98], [FLUH00], [MANT01]). None of these approaches is practical against, RC4 with a reasonable key length, such as 128 bits. A more serious problem is reported, in [FLUH01]. The authors demonstrate that the WEP protocol, intended to provide, confidentiality on 802.11 wireless LAN networks, is vulnerable to a particular attack, approach. In essence, the problem is not with RC4 itself but the way in which keys are, generated for use as input to RC4. This particular problem does not appear to be relevant to other applications using RC4 and can be remedied in WEP by changing the way, in which keys are generated. This problem points out the difficulty in designing a secure, system that involves both cryptographic functions and protocols that make use of them., More recently, [PAUL07] revealed a more fundamental vulnerability in the, RC4 key scheduling algorithm that reduces the amount of effort to discover the, key. Recent cryptanalysis results [ALFA13] exploit biases in the RC4 keystream to, recover repeatedly encrypted plaintexts. As a result of the discovered weaknesses,, particularly those reported in [ALFA13], the IETF issued RFC 7465 prohibiting the, use of RC4 in TLS (Prohibiting RC4 Cipher Suites, February 2015). In its latest TLS, guidelines, NIST also prohibited the use of RC4 for government use (SP 800-52,, Guidelines for the Selection, Configuration, and Use of Transport Layer Security, (TLS) Implementations, September 2013)., , 8.6 TRUE RANDOM NUMBER GENERATORS, Entropy Sources, A true random number generator (TRNG) uses a nondeterministic source to produce randomness. Most operate by measuring unpredictable natural processes, such, as pulse detectors of ionizing radiation events, gas discharge tubes, and leaky capacitors. Intel has developed a commercially available chip that samples thermal noise, by sampling the output of a coupled pair of inverters. LavaRnd is an open source, project for creating truly random numbers using inexpensive cameras, open source, code, and inexpensive hardware. The system uses a saturated CCD in a light-tight, can as a chaotic source to produce the seed. Software processes the result into truly, random numbers in a variety of formats., RFC 4086 lists the following possible sources of randomness that, with care,, easily can be used on a computer to generate true random sequences., ■, , ■, , Sound/video input: Many computers are built with inputs that digitize some, real-world analog source, such as sound from a microphone or video input, from a camera. The “input” from a sound digitizer with no source plugged in or, from a camera with the lens cap on is essentially thermal noise. If the system, has enough gain to detect anything, such input can provide reasonably high, quality random bits., Disk drives: Disk drives have small random fluctuations in their rotational, speed due to chaotic air turbulence [JAKO98]. The addition of low-level disk, seek-time instrumentation produces a series of measurements that contain this, , Hiva-Network.Com
Page 273 :
272, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , randomness. Such data is usually highly correlated, so significant processing is, needed. Nevertheless, experimentation a decade ago showed that, with such, processing, even slow disk drives on the slower computers of that day could, easily produce 100 bits a minute or more of excellent random data., There is also an online service (random.org), which can deliver random, sequences securely over the Internet., , Comparison of PRNGs and TRNGs, Table 8.5 summarizes the principal differences between PRNGs and TRNGs., PRNGs are efficient, meaning they can produce many numbers in a short time, and, deterministic, meaning that a given sequence of numbers can be reproduced at a, later date if the starting point in the sequence is known. Efficiency is a nice characteristic if your application needs many numbers, and determinism is handy if you, need to replay the same sequence of numbers again at a later stage. PRNGs are, typically also periodic, which means that the sequence will eventually repeat itself., While periodicity is hardly ever a desirable characteristic, modern PRNGs have a, period that is so long that it can be ignored for most practical purposes., TRNGs are generally rather inefficient compared to PRNGs, taking considerably longer time to produce numbers. This presents a difficulty in many applications. For example, cryptography system in banking or national security might need, to generate millions of random bits per second. TRNGs are also nondeterministic,, meaning that a given sequence of numbers cannot be reproduced, although the same, sequence may of course occur several times by chance. TRNGs have no period., , Conditioning2, A TRNG may produce an output that is biased in some way, such as having more, ones than zeros or vice versa. More generally, NIST SP 800-90B defines a random, process as biased with respect to an assumed discrete set of potential outcomes, (i.e., possible output values) if some of those outcomes have a greater probability, of occurring than do others. For example, a physical source such as electronic noise, may contain a superposition of regular structures, such as waves or other periodic, phenomena, which may appear to be random, yet are determined to be non-random, using statistical tests., Table 8.5, , Comparison of PRNGs and TRNGs, , Efficiency, Determinism, Periodicity, , 2, , Pseudorandom Number, Generators, , True Random Number, Generators, , Very efficient, Deterministic, Periodic, , Generally inefficient, Nondeterministic, Aperiodic, , The reader unfamiliar with the concepts of entropy and min-entropy should read Appendix F before, proceeding.
Page 274 :
8.6 / TRUE RANDOM NUMBER GENERATORS, , 273, , In addition to bias, another concept used by SP 800-98B is that of entropy rate., SP 800-90B defines entropy rate as the rate at which a digitized noise source (or, entropy source) provides entropy; it is computed as the assessed amount of entropy, provided by a bit string output from the source, divided by the total number of, bits in the bit string (yielding assessed bits of entropy per output bit). This will be, a value between 0 (no entropy) and 1 (full entropy). Entropy rate is a measure, of the randomness or unpredictability of a bit string. Another way of expressing it is that the entropy rate is k/n for a random source of length n bits and minentropy k. Min-entropy is a measure of the number of random bits and is explained, in Appendix F. In essence, a block of bits or a bit stream that is unbiased, and in, which each bit and each group of bits is independent of all other bits and groups of, bits will have an entropy rate of 1., For hardware sources of random bits, the recommended approach is to assume, that there may be bias and/or an entropy rate of less than 1 and to apply techniques, to further “randomize” the bits. Various methods of modifying a bit stream for this, purpose have been developed. These are referred to as conditioning algorithms or, deskewing algorithms., Typically, conditioning is done by using a cryptographic algorithm to “scramble”, the random bits so as to eliminate bias and increase entropy. The two most common, approaches are the use of a hash function or a symmetric block cipher., HASH FUNCTION As we describe in Chapter 11, a hash function produces an n-bit, output from an input of arbitrary length. A simple way to use a hash function for, conditioning is as follows. Blocks of m input bits, with m Ú n, are passed through, the hash function and the n output bits are used as random bits. To generate a, stream of random bits, successive input blocks pass through the hash function to, produce successive hashed output blocks., Operating systems typically provide a built-in mechanism for generating random numbers. For example, Linux uses four entropy sources: mouse and keyboard, activity, disk I/O operations, and specific interrupts. Bits are generated from these, four sources and combined in a pooled buffer. When random bits are needed, the, appropriate number of bits are read from the buffer and passed through the SHA-1, hash function [GUTT06]., A more complex approach is the hash derivation function specified in, SP800-90A. Hash_df can be defined as follows:, Parameters:, input_string: The string to be hashed., outlen: Output length., no_of_bits_to_return: The number of bits to be returned by Hash_df. The maximum length (max_number_of_bits) is implementation dependent, but shall be, less than or equal to (255 * outlen). no_of_bits_to_return is represented as a, 32-bit integer., requested_bits: The result of performing the Hash_df.
Page 275 :
274, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , Hash_df Process:, 1. temp = the Null string, no_of_bits_to_return, m, outlen, counter = 0x01 Comment: An 8-bit binary value representing the integer “1”., For i = 1 to len do Comment: In 4.1, no_of_bits_to_return is used as a 32-bit, string., 4.1. temp = temp } Hash (counter } no_of_bits_to_return } input_string)., 4.2. counter = counter + 1., requested_bits = leftmost (temp, no_of_bits_to_return)., Return (SUCCESS, requested_bits)., , 2. len = l, 3., 4., , 5., 6., , This algorithm takes an input block of bits of arbitrary length and returns the, requested number of bits, which may be up to 255 times as long as the hash output, length., The reader may be uneasy that the output consists of hashed blocks in which, the input to the hash function for each block is the same input string and differs, only by the value of the counter. However, cryptographically strong hash functions,, such as the SHA family, provide excellent diffusion (as defined in Chapter 4) so that, change in the counter value results in dramatically different outputs., BLOCK CIPHER Instead of a hash function, a block cipher such as AES can be, used to scramble the TRNG bits. Using AES, a simple approach would be to take, 128-bit blocks of TRNG bits and encrypt each block with AES and some arbitrary, key. SP 800-90B outlines an approach similar to the hash_df function described previously. The Intel implementation discussed subsequently provides an example of, using AES for conditioning., , Health Testing, Figure 8.9 provides a general model for a nondeterministic random bit generator., A hardware noise source produces a true random output. This is digitized to produce true, or nondeterministic, source of bits. This bit source then passes through a, conditioning module to mitigate bias and maximize entropy., Figure 8.9 also shows a health-testing module, which is used on the outputs, of both the digitizer and conditioner. In essence, health testing is used to validate, that the noise source is working as expected and that the conditioning module is, produced output with the desired characteristics. Both forms of health testing are, recommended by SP 800-90B., HEALTH TESTS ON THE NOISE SOURCE The nature of the health testing of the noise, source depends strongly on the technology used to produce noise. In general, we, can assume that the digitized output of the noise source will exhibit some bias. Thus,, the traditional statistical tests, such as those defined in SP 800-22 and discussed in, Section 8.1, are not useful for monitoring the noise source, because the noise source
Page 276 :
8.6 / TRUE RANDOM NUMBER GENERATORS, , NONDETERMINISTIC, RANDOM, BIT GENERATOR, , 275, , Nondetermistic bit source, Noise source, , Digitization, A, , Health, testing, , Conditioning, B, , Output, , Figure 8.9, , NRBG Model, , is likely to always fail. Rather, the tests on the noise source need to be tailored to, the expected statistical behavior of the correctly operating noise source. The goal, is not to determine if the source is unbiased, which it isn’t, but if it is operating, as expected., SP 800-90B specifies that continuous tests be done on digitized samples, obtained from the noise source (point A in Figure 8.9). The purpose is to test for, variability. More specifically, the purpose is to determine if the noise source is producing at the expected entropy rate. SP 800-909B mandates the use of two tests: the, Repetition Count Test and the Adaptive Proportion Test., The Repetition Count Test is designed to quickly detect a catastrophic failure, that causes the noise source to become “stuck” on a single output value for a long, time. For this test, it is assumed that a given noise source is assessed to have a given, min-entropy value of H. The entropy is expressed as the amount of entropy per sample, where a sample could be a single bit or some block of bits of length n. With an, assessed value of H, it is straightforward to calculate the probability that a sequence, of C consecutive samples will yield identical sample values. For example, a noise, source with one bit of min-entropy per sample has no more than a 1/2 probability, of repeating some sample value twice in a row, no more than 1/4 probability of, repeating some sample value three times in a row, and in general, no more than, (1/2)C - 1 probability of repeating some sample value C times in a row. To generalize,, for a noise source with H bits of min-entropy per sample, we have:, Pr[C identical samples in a row] … (2-H)(C - 1), The Repetition Count Test involves looking for consecutive identical samples. If the count reaches some cutoff value C, then an error condition is raised., To determine the value of C used in the test, the test must be configured with
Page 277 :
276, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , a parameter W, which is the acceptable false-positive probability associated with, an alarm triggered by C repeated sample values. To avoid false positives, W should, be set at some very small number greater than 0. Given W, we can now determine, the value of C. Specifically, we want C to be the smallest number that satisfies the, equation W … (2-H)(C - 1). Reworking terms, this gives us a value of:, C = l1 +, , -log(W), m, H, , For example, for W = 2-30, an entropy source with H = 7.3 bits per sample, would have a cutoff value C of l 1 +, , 30, m = 6., 7.3, , The Repetition Count Test starts by recording a sample value and then counting the number of repetitions of the same value. If the counter reaches the cutoff, value C, an error is reported. If a sample value is encountered that differs from the, preceding sample, then the counter is reset to 1 and the algorithm starts over., The Adaptive Proportion Test is designed to detect a large loss of entropy,, such as might occur as a result of some physical failure or environmental change, affecting the noise source. The test continuously measures the local frequency of, occurrence of some sample value in a sequence of noise source samples to determine, if the sample occurs too frequently., The test starts by recording a sample value and then observes N successive, sample values. If the initial sample value is observed at least C times, then an error, condition is reported. SP 800-90B recommends that a probability of a false positive, of W = 2-30 be used for the test and provides guidance on the selection of values, for N and C., HEALTH TESTS ON THE CONDITIONING FUNCTION SP 800-90B specifies that health, tests should also be applied to the output of the conditioning component (point B, in Figure 8.9), but does not indicate which tests to use. The purpose of the health, tests on the conditioning component is to assure that the output behaves as a true, random bit stream. Thus, it is reasonable to use the tests for randomness defined in, SP 800-22, and described in Section 8.1., , Intel Digital Random Number Generator, As was mentioned, TRNGs have traditionally been used only for key generation, and other applications where only a small number of random bits were required., This is because TRNGs have generally been inefficient, with a low bit rate of, random bit production., The first commercially available TRNG that achieves bit production rates, comparable with that of PRNGs is the Intel digital random number generator, (DRNG) [TAYL11, MECH14], offered on new multicore chips since May 2012.3, , 3, , It is unfortunate that Intel chose the acronym DRNG for an NRBG. It confuses with DRBG, which is, a pseudorandom number bit generator.
Page 278 :
8.6 / TRUE RANDOM NUMBER GENERATORS, , 277, , Two notable aspects of the DRNG:, 1. It is implemented entirely in hardware. This provides greater security than a, facility that includes a software component. A hardware-only implementation should also be able to achieve greater computation speed than a software, module., 2. The entire DRNG is on the same multicore chip as the processors. This eliminates the I/O delays found in other hardware random number generators., DRNG HARDWARE ARCHITECTURE Figure 8.10 shows the overall structure of the, DRNG. The first stage of the DRNG generates random numbers from thermal, noise. The heart of the stage consists of two inverters (NOT gates), with the output, of each inverter connected to the input of the other. Such an arrangement has two, stable states, with one inverter having an output of logical 1 and the other having an, output of logical 0. The circuit is then configured so that both inverters are forced, to have the same indeterminate state (both inputs and both outputs at logical 1) by, clock pulses. Random thermal noise within the inverters soon jostles the two inverters into a mutually stable state. Additional circuitry is intended to compensate for, any biases or correlations. This stage is capable, with current hardware, of generating random bits at a rate of 4 Gbps., , Digital Random Number Generator, , Hardware, entropy, source, , Hardware, AES-CBCMAC based, conditioner, , Hardware, SP 800-90A, AES-CTR, based, DRBG, , Hardware, SP 80090B & C, ENRNG, , Core 0, , RDSEED, instruction, , RDRAND, instruction, , Core N–1, , RDSEED, instruction, , RDRAND, instruction, , Processor, chip, , Figure 8.10 Intel Processor Chip with Random Number Generator
Page 279 :
278, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , The output of the first stage is generated 512 bits at a time. To assure that, the bit stream does not have skew or bias, a conditioner randomizes its input using, a cryptographic function. In this case, the function is referred to as CBC-MAC or, CMAC, as specified in NIST SP 800-38B. In essence, CMAC encrypts its input using, the cipher block chaining (CBC) mode (Figure 8.4) and outputs the final block., We examine CMAC in detail in Chapter 12. The output of this stage is generated, 256 bits at a time and is intended to exhibit true randomness with no skew or bias., While the hardware’s circuitry generates random numbers from thermal noise, much more quickly than its predecessors, it is still not fast enough for some of today’s computing requirements. To enable the DRNG to generate random numbers, as quickly as a software DRBG, and also maintain the high quality of the random, numbers, a third stage is added. This stage uses the 256-bit random numbers to, seed a cryptographically secure DRBG that creates 128-bit numbers. From one, 256-bit seed, the DRBG can output many pseudorandom numbers, exceeding the, 3-Gbps rate of the entropy source. An upper bound of 511 128-bit samples can, be generated per seed. The algorithm used for this stage is CTR_DRBG, described, in Section 8.3., The output of the PRNG stage is available to each of the cores on the chip via, the RDRAND instruction. RDRAND retrieves a 16-, 32-, or 64-bit random value, and makes it available in a software-accessible register., Preliminary data from a pre-production sample on a system with a third, generation Intel® Core™ family processor produced the following performance, [INTE12]: up to 70 million RDRAND invocations per second, and a random data, production rate of over 4 Gbps., The output of the conditioner is also made available to another module,, known as an enhanced nondeterministic random number generator (ENRNG) that, provides random numbers that can be used as seeds for various cryptographic algorithms. The ENRNG is compliant with specifications in SP 800-90B and 900-90C., The output of the ENRNG stage is available to each of the cores on the chip via, the RDSEED instruction. RDSEED retrieves a hardware-generated random seed, value from the ENRNG and stores it in the destination register given as an argument to the instruction., DRNG LOGICAL STRUCTURE Figure 8.11 provides a simplified view of the logical, flow of the Intel DRBG. As was described, the heart of the hardware entropy source, is a pair of inverters that feed each other. Two transistors, driven by the same clock,, force the inputs and outputs of both inverters to the logical 1 state. Because this is, an unstable state, thermal noise will cause the configuration to settle randomly into, a stable state with either Node A at logical 1 and Node B at logical 0, or the reverse., Thus the module generates random bits at the clock rate., The output of the entropy source is collected 512 bits at a time and used to, feed to two CBC hardware implementations using AES encryption. Each implementation takes two blocks of 128 bits of “plaintext” and encrypts using the CBC, mode. The output of the second encryption is retained. For both CBC modules, an, all-zeros key is used initially. Subsequently, the output of the PRNG stage is fed, back to become the key for the conditioner stage.
Page 280 :
8.6 / TRUE RANDOM NUMBER GENERATORS, , Transistor 1, , 279, , Transistor 2, , Clock, Inverters, Node A, , Node B, , Hardware, entropy, source, , 128 bits, , 128 bits, , K, , K, , Encrypt, , AES CBC, Mac-based, conditioner, 0, , 1st, time, , Encrypt, , 128 bits, , K, , K, , Encrypt, , 128 bits, , Encrypt, , 128 bits, , 1, , +, , 128 bits, , 1, , +, , 128 bits, , Key, , V, , K=0, Encrypt, , AES-CTRbased, PRNG, , Encrypt, , 256 bits, , Pseudorandom, bits, , Figure 8.11, , Intel DRNG Logical Structure, , The output of the conditioner stage consists of 256 bits. This block is provided, as input to the update function of the DRGB stage. The update function is initialized with the all-zeros key and the counter value 0. The function is iterated twice, to produce a 256-block, which is then XORed with the input from the conditioner, stage. The results are used as the 128-bit key and the 128-bit seed for the generate, function. The generate function produces pseudorandom bits in 128-bit blocks.
Page 281 :
280, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, , 8.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, backward unpredictability, Blum Blum Shub generator, deskewing, entropy source, forward unpredictability, keystream, linear congruential generator, , pseudorandom function, (PRF), pseudorandom number, generator (PRNG), randomness, RC4, seed, , stream cipher, skew, true random number, generator (TRNG), unpredictability, , Review Questions, 8.1, 8.2, 8.3, 8.4, , List two criteria to validate the randomness of a sequence of numbers., What is ANSI X9.17 PRNG?, What is the difference between a one-time pad and a stream cipher?, List a few applications of stream ciphers and block ciphers., , Problems, 8.1, , If we take the linear congruential algorithm with an additive component of 0,, Xn + 1 = (aXn) mod m, , 8.2, , Then it can be shown that if m is prime and if a given value of a produces the maximum period of m - 1, then ak will also produce the maximum period, provided that, k is less than m and that k and m - 1 are relatively prime. Demonstrate this by using, X0 = 1 and m = 31 and producing the sequences for ak = 3, 32, 33, and 34., a. What is the maximum period obtainable from the following generator?, Xn + 1 = (aXn) mod 24, , 8.3, , 8.4, , b. What should be the value of a?, c. What restrictions are required on the seed?, You may wonder why the modulus m = 231 - 1 was chosen for the linear congruential method instead of simply 231, because this latter number can be represented with, no additional bits and the mod operation should be easier to perform. In general, the, modulus 2k - 1 is preferable to 2k. Why is this so?, With the linear congruential algorithm, a choice of parameters that provides a full, period does not necessarily provide a good randomization. For example, consider the, following two generators:, Xn + 1 = (11Xn) mod 13, Xn + 1 = (2Xn) mod 13, Write out the two sequences to show that both are full period. Which one appears, more random to you?, , Hiva-Network.Com
Page 282 :
8.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 8.5, , 8.6, , 8.7, , 8.8, , 8.9, , 281, , In any use of pseudorandom numbers, whether for encryption, simulation, or statistical design, it is dangerous to trust blindly the random number generator that happens, to be available in your computer’s system library. [PARK88] found that many contemporary textbooks and programming packages make use of flawed algorithms for, pseudorandom number generation. This exercise will enable you to test your system., The test is based on a theorem attributed to Ernesto Cesaro (see [KNUT98] for a, proof), which states the following: Given two randomly chosen integers, x and y, the, probability that gcd(x, y) = 1 is 6/p2. Use this theorem in a program to determine, statistically the value of p. The main program should call three subprograms: the random number generator from the system library to generate the random integers; a, subprogram to calculate the greatest common divisor of two integers using Euclid’s, Algorithm; and a subprogram that calculates square roots. If these latter two programs are not available, you will have to write them as well. The main program should, loop through a large number of random numbers to give an estimate of the aforementioned probability. From this, it is a simple matter to solve for your estimate of p., If the result is close to 3.14, congratulations! If not, then the result is probably low,, usually a value of around 2.7. Why would such an inferior result be obtained?, What RC4 key value will leave S unchanged during initialization? That is, after the, initial permutation of S, the entries of S will be equal to the values from 0 through 255, in ascending order., RC4 has a secret internal state which is a permutation of all the possible values of the, vector S and the two indices i and j., a. Using a straightforward scheme to store the internal state, how many bits are used?, b. Suppose we think of it from the point of view of how much information is represented by the state. In that case, we need to determine how may different states, there are, then take the log to base 2 to find out how many bits of information this, represents. Using this approach, how many bits would be needed to represent the, state?, Alice and Bob agree to communicate privately via email using a scheme based on, RC4, but they want to avoid using a new secret key for each transmission. Alice and, Bob privately agree on a 128-bit key k. To encrypt a message m, consisting of a string, of bits, the following procedure is used., 1. Choose a random 64-bit value v, 2. Generate the ciphertext c = RC4(v } k) ⊕ m, 3. Send the bit string (v } c), a. Suppose Alice uses this procedure to send a message m to Bob. Describe how, Bob can recover the message m from (v } c) using k., b. If an adversary observes several values (v1 } c1), (v2 } c2), c transmitted, between Alice and Bob, how can he/she determine when the same key stream, has been used to encrypt two messages?, c. Approximately how many messages can Alice expect to send before the same, key stream will be used twice? Use the result from the birthday paradox, described in Appendix U., d. What does this imply about the lifetime of the key k (i.e., the number of messages that can be encrypted using k)?, Suppose you have a true random bit generator where each bit in the generated stream, has the same probability of being a 0 or 1 as any other bit in the stream and that the, bits are not correlated; that is the bits are generated from identical independent distribution. However, the bit stream is biased. The probability of a 1 is 0.5 + 0 and the, probability of a 0 is 0.5 - 0, where 0 6 0 6 0.5. A simple conditioning algorithm is, as follows: Examine the bit stream as a sequence of nonoverlapping pairs. Discard all, 00 and 11 pairs. Replace each 01 pair with 0 and each 10 pair with 1.
Page 283 :
282, , CHAPTER 8 / RANDOM BIT GENERATION AND STREAM CIPHERS, a., b., c., d., , 8.10, , 8.11, , What is the probability of occurrence of each pair in the original sequence?, What is the probability of occurrence of 0 and 1 in the modified sequence?, What is the expected number of input bits to produce x output bits?, Suppose that the algorithm uses overlapping successive bit pairs instead of nonoverlapping successive bit pairs. That is, the first output bit is based on input bits 1, and 2, the second output bit is based on input bits 2 and 3, and so on. What can you, say about the output bit stream?, Another approach to conditioning is to consider the bit stream as a sequence of nonoverlapping groups of n bits each and output the parity of each group. That is, if a, group contains an odd number of ones, the output is 1; otherwise the output is 0., a. Express this operation in terms of a basic Boolean function., b. Assume, as in the preceding problem, that the probability of a 1 is 0.5 + 0. If each, group consists of 2 bits, what is the probability of an output of 1?, c. If each group consists of 4 bits, what is the probability of an output of 1?, d. Generalize the result to find the probability of an output of 1 for input groups of, n bits., It is important to note that the Repetition Count Test described in Section 8.6 is not a, very powerful health test. It is able to detect only catastrophic failures of an entropy, source. For example, a noise source evaluated at 8 bits of min-entropy per sample, has a cutoff value of 5 repetitions to ensure a false-positive rate of approximately, once per four billion samples generated. If that noise source somehow failed to the, point that it was providing only 6 bits of min-entropy per sample, how many samples, would be expected to be needed before the Repetition Count Test would notice the, problem?
Page 284 :
PART THREE: ASYMMETRIC CIPHERS, CHAPTER, , Public-Key Cryptography, and RSA, 9.1, , Principles of Public-Key Cryptosystems, Public-Key Cryptosystems, Applications for Public-Key Cryptosystems, Requirements for Public-Key Cryptography, Public-Key Cryptanalysis, , 9.2, , The RSA Algorithm, Description of the Algorithm, Computational Aspects, The Security of RSA, , 9.3, , Key Terms, Review Questions, and Problems, , 283
Page 285 :
284, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, ◆, , Present an overview of the basic principles of public-key cryptosystems., Explain the two distinct uses of public-key cryptosystems., List and explain the requirements for a public-key cryptosystem., Present an overview of the RSA algorithm., Understand the timing attack., Summarize the relevant issues related to the complexity of algorithms., , The development of public-key, or asymmetric, cryptography is the greatest and perhaps the only true revolution in the entire history of cryptography. From its earliest, beginnings to modern times, virtually all cryptographic systems have been based on, the elementary tools of substitution and permutation. After millennia of working with, algorithms that could be calculated by hand, a major advance in symmetric cryptography occurred with the development of the rotor encryption/decryption machine. The, electromechanical rotor enabled the development of fiendishly complex cipher systems. With the availability of computers, even more complex systems were devised,, the most prominent of which was the Lucifer effort at IBM that culminated in the Data, Encryption Standard (DES). But both rotor machines and DES, although representing significant advances, still relied on the bread-and-butter tools of substitution and, permutation., Public-key cryptography provides a radical departure from all that has gone before. For one thing, public-key algorithms are based on mathematical functions rather, than on substitution and permutation. More important, public-key cryptography is, asymmetric, involving the use of two separate keys, in contrast to symmetric encryption, which uses only one key. The use of two keys has profound consequences in the, areas of confidentiality, key distribution, and authentication, as we shall see., Before proceeding, we should mention several common misconceptions concerning public-key encryption. One such misconception is that public-key encryption, is more secure from cryptanalysis than is symmetric encryption. In fact, the security of, any encryption scheme depends on the length of the key and the computational work, involved in breaking a cipher. There is nothing in principle about either symmetric or, public-key encryption that makes one superior to another from the point of view of, resisting cryptanalysis., A second misconception is that public-key encryption is a general-purpose technique that has made symmetric encryption obsolete. On the contrary, because of the, computational overhead of current public-key encryption schemes, there seems no, foreseeable likelihood that symmetric encryption will be abandoned. As one of the, inventors of public-key encryption has put it [DIFF88], “the restriction of public-key, cryptography to key management and signature applications is almost universally, accepted.”
Page 286 :
9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, , 285, , Table 9.1 Terminology Related to Asymmetric Encryption, Asymmetric Keys, Two related keys, a public key and a private key, that are used to perform complementary operations, such as, encryption and decryption or signature generation and signature verification., Public Key Certificate, A digital document issued and digitally signed by the private key of a Certification Authority that binds the, name of a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate, has sole control and access to the corresponding private key., Public Key (Asymmetric) Cryptographic Algorithm, A cryptographic algorithm that uses two related keys, a public key and a private key. The two keys have the, property that deriving the private key from the public key is computationally infeasible., Public Key Infrastructure (PKI), A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key, certificates., Source: Glossary of Key Information Security Terms, NIST IR 7298 [KISS06]., , Finally, there is a feeling that key distribution is trivial when using public-key, encryption, compared to the rather cumbersome handshaking involved with key distribution centers for symmetric encryption. In fact, some form of protocol is needed,, generally involving a central agent, and the procedures involved are not simpler nor, any more efficient than those required for symmetric encryption (e.g., see analysis in, [NEED78])., This chapter and the next provide an overview of public-key cryptography. First,, we look at its conceptual framework. Interestingly, the concept for this technique was, developed and published before it was shown to be practical to adopt it. Next, we examine the RSA algorithm, which is the most important encryption/decryption algorithm that has been shown to be feasible for public-key encryption. Other important, public-key cryptographic algorithms are covered in Chapter 10., Much of the theory of public-key cryptosystems is based on number theory. If, one is prepared to accept the results given in this chapter, an understanding of number, theory is not strictly necessary. However, to gain a full appreciation of public-key, algorithms, some understanding of number theory is required. Chapter 2 provides the, necessary background in number theory., Table 9.1 defines some key terms., , 9.1 PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, The concept of public-key cryptography evolved from an attempt to attack two of, the most difficult problems associated with symmetric encryption. The first problem, is that of key distribution, which is examined in some detail in Chapter 14., As Chapter 14 discusses, key distribution under symmetric encryption requires, either (1) that two communicants already share a key, which somehow has been distributed to them; or (2) the use of a key distribution center. Whitfield Diffie, one
Page 287 :
286, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , of the discoverers of public-key encryption (along with Martin Hellman, both at, Stanford University at the time), reasoned that this second requirement negated the, very essence of cryptography: the ability to maintain total secrecy over your own, communication. As Diffie put it [DIFF88], “what good would it do after all to develop impenetrable cryptosystems, if their users were forced to share their keys with, a KDC that could be compromised by either burglary or subpoena?”, The second problem that Diffie pondered, and one that was apparently unrelated to the first, was that of digital signatures. If the use of cryptography was to, become widespread, not just in military situations but for commercial and private, purposes, then electronic messages and documents would need the equivalent of, signatures used in paper documents. That is, could a method be devised that would, stipulate, to the satisfaction of all parties, that a digital message had been sent by a, particular person? This is a somewhat broader requirement than that of authentication, and its characteristics and ramifications are explored in Chapter 13., Diffie and Hellman achieved an astounding breakthrough in 1976 [DIFF76 a, b], by coming up with a method that addressed both problems and was radically different, from all previous approaches to cryptography, going back over four millennia.1, In the next subsection, we look at the overall framework for public-key cryptography. Then we examine the requirements for the encryption/decryption algorithm that is at the heart of the scheme., , Public-Key Cryptosystems, Asymmetric algorithms rely on one key for encryption and a different but related, key for decryption. These algorithms have the following important characteristic., ■, , It is computationally infeasible to determine the decryption key given only, knowledge of the cryptographic algorithm and the encryption key., , In addition, some algorithms, such as RSA, also exhibit the following characteristic., ■, , Either of the two related keys can be used for encryption, with the other used, for decryption., , A public-key encryption scheme has six ingredients (Figure 9.1a; compare, with Figure 3.1)., ■, ■, , 1, , Plaintext: This is the readable message or data that is fed into the algorithm, as input., Encryption algorithm: The encryption algorithm performs various transformations on the plaintext., , Diffie and Hellman first publicly introduced the concepts of public-key cryptography in 1976. Hellman, credits Merkle with independently discovering the concept at that same time, although Merkle did not, publish until 1978 [MERK78]. In fact, the first unclassified document describing public-key distribution, and public-key cryptography was a 1974 project proposal by Merkle (http://merkle.com/1974). However,, this is not the true beginning. Admiral Bobby Inman, while director of the National Security Agency, (NSA), claimed that public-key cryptography had been discovered at NSA in the mid-1960s [SIMM93]., The first documented introduction of these concepts came in 1970, from the Communications-Electronics, Security Group, Britain’s counterpart to NSA, in a classified report by James Ellis [ELLI70]. Ellis referred to the technique as nonsecret encryption and describes the discovery in [ELLI99].
Page 288 :
9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, , 287, , Bobs's, public-key, ring, Joy, , Ted, Alice, , Mike, PUa, , Alice's public, key, , PRa, , Alice's private, key, X=, D[PRa, Y], , Transmitted, ciphertext, , X, , Y = E[PUa, X], Plaintext, input, , Encryption algorithm, (e.g., RSA), Bob, , Decryption algorithm, , (a) Encryption with public key, , Plaintext, output, , Alice, , Alice's, public key, ring, Joy, , Ted, Mike, , PRb, , PUb, , Bob's private, key, , Bob's public, key, X=, D[PUb, Y], , Transmitted, ciphertext, , X, , Bob, , Y = E[PRb, X], Plaintext, input, , Encryption algorithm, (e.g., RSA), Bob, , Decryption algorithm, , (b) Encryption with private key, , Plaintext, output, , Alice, , Figure 9.1 Public-Key Cryptography, , ■, , ■, , Public and private keys: This is a pair of keys that have been selected so that if, one is used for encryption, the other is used for decryption. The exact transformations performed by the algorithm depend on the public or private key that, is provided as input., Ciphertext: This is the encrypted message produced as output. It depends on, the plaintext and the key. For a given message, two different keys will produce, two different ciphertexts.
Page 289 :
288, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, ■, , Decryption algorithm: This algorithm accepts the ciphertext and the matching, key and produces the original plaintext., The essential steps are the following., , 1. Each user generates a pair of keys to be used for the encryption and decryption of messages., 2. Each user places one of the two keys in a public register or other accessible, file. This is the public key. The companion key is kept private. As Figure 9.1a, suggests, each user maintains a collection of public keys obtained from others., 3. If Bob wishes to send a confidential message to Alice, Bob encrypts the message using Alice’s public key., 4. When Alice receives the message, she decrypts it using her private key. No, other recipient can decrypt the message because only Alice knows Alice’s private key., With this approach, all participants have access to public keys, and private, keys are generated locally by each participant and therefore need never be distributed. As long as a user’s private key remains protected and secret, incoming communication is secure. At any time, a system can change its private key and publish, the companion public key to replace its old public key., Table 9.2 summarizes some of the important aspects of symmetric and publickey encryption. To discriminate between the two, we refer to the key used in symmetric encryption as a secret key. The two keys used for asymmetric encryption are, referred to as the public key and the private key.2 Invariably, the private key is kept, secret, but it is referred to as a private key rather than a secret key to avoid confusion with symmetric encryption., Let us take a closer look at the essential elements of a public-key encryption, scheme, using Figure 9.2 (compare with Figure 3.2). There is some source A that, produces a message in plaintext, X = [X1, X2, c , XM]. The M elements of X are, letters in some finite alphabet. The message is intended for destination B. B generates a related pair of keys: a public key, PUb, and a private key, PRb. PRb is known, only to B, whereas PUb is publicly available and therefore accessible by A., With the message X and the encryption key PUb as input, A forms the ciphertext Y = [Y1, Y2, c , YN]:, Y = E(PUb, X), The intended receiver, in possession of the matching private key, is able to invert, the transformation:, X = D(PRb,Y), , 2, , The following notation is used consistently throughout. A secret key is represented by Km, where m is, some modifier; for example, Ka is a secret key owned by user A. A public key is represented by PUa, for, user A, and the corresponding private key is PRa. Encryption of plaintext X can be performed with a, secret key, a public key, or a private key, denoted by E(Ka, X), E(PUa, X), and E(PRa, X), respectively., Similarly, decryption of ciphertext Y can be performed with a secret key, a public key, or a private key,, denoted by D(Ka, Y), D(PUa, Y), and D(PRa, Y), respectively.
Page 290 :
9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, Table 9.2, , 289, , Conventional and Public-Key Encryption, Conventional Encryption, , Public-Key Encryption, , Needed to Work:, , Needed to Work:, , 1. The same algorithm with the same key is, used for encryption and decryption., 2. The sender and receiver must share the, algorithm and the key., Needed for Security:, , 1. One algorithm is used for encryption and a related, algorithm for decryption with a pair of keys, one for, encryption and one for decryption., 2. The sender and receiver must each have one of the, matched pair of keys (not the same one)., Needed for Security:, , 1. The key must be kept secret., , 1. One of the two keys must be kept secret., , 2. It must be impossible or at least impractical, to decipher a message if the key is kept, secret., , 2. It must be impossible or at least impractical to, decipher a message if one of the keys is kept secret., , 3. Knowledge of the algorithm plus samples of, ciphertext must be insufficient to determine, the key., , 3. Knowledge of the algorithm plus one of the keys, plus samples of ciphertext must be insufficient to, determine the other key., , An adversary, observing Y and having access to PUb, but not having access to PRb, or X, must attempt to recover X and/or PRb. It is assumed that the adversary does, have knowledge of the encryption (E) and decryption (D) algorithms. If the adversary is interested only in this particular message, then the focus of effort is to, n . Often, however, the adversary is, recover X by generating a plaintext estimate X, interested in being able to read future messages as well, in which case an attempt is, made to recover PRb by generating an estimate PRnb., , Cryptanalyst, , Source A, , Message, source, , X, , ^, X, ^, PRb, , Destination B, , Encryption, algorithm, , Y = E[PUb, X], , Decryption, algorithm, , PUb, , PRb, Key pair, source, , Figure 9.2, , Public-Key Cryptosystem: Confidentiality, , Hiva-Network.Com, , Destination, X=, D[PRb, Y]
Page 291 :
290, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , We mentioned earlier that either of the two related keys can be used for encryption, with the other being used for decryption. This enables a rather different cryptographic scheme to be implemented. Whereas the scheme illustrated in, Figure 9.2 provides confidentiality, Figures 9.1b and 9.3 show the use of public-key, encryption to provide authentication:, Y = E(PRa,X), X = D(PUa,Y), In this case, A prepares a message to B and encrypts it using A’s private key, before transmitting it. B can decrypt the message using A’s public key. Because the, message was encrypted using A’s private key, only A could have prepared the message. Therefore, the entire encrypted message serves as a digital signature. In addition, it is impossible to alter the message without access to A’s private key, so the, message is authenticated both in terms of source and in terms of data integrity., In the preceding scheme, the entire message is encrypted, which, although validating both author and contents, requires a great deal of storage. Each document, must be kept in plaintext to be used for practical purposes. A copy also must be, stored in ciphertext so that the origin and contents can be verified in case of a dispute. A more efficient way of achieving the same results is to encrypt a small block, of bits that is a function of the document. Such a block, called an authenticator,, must have the property that it is infeasible to change the document without changing the authenticator. If the authenticator is encrypted with the sender’s private, key, it serves as a signature that verifies origin, content, and sequencing. Chapter 13, examines this technique in detail., , Cryptanalyst, , Source A, , Message, source, , X, , Destination B, , Encryption, algorithm, , PRa, , Y = E[PRa, X], , PUa, Key pair, source, , Figure 9.3, , ^, PRa, , Public-Key Cryptosystem: Authentication, , Decryption, algorithm, , Destination, X=, D[PUa, Y]
Page 292 :
9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, , 291, , It is important to emphasize that the encryption process depicted in Figures 9.1b, and 9.3 does not provide confidentiality. That is, the message being sent is safe from, alteration but not from eavesdropping. This is obvious in the case of a signature, based on a portion of the message, because the rest of the message is transmitted in, the clear. Even in the case of complete encryption, as shown in Figure 9.3, there is, no protection of confidentiality because any observer can decrypt the message by, using the sender’s public key., It is, however, possible to provide both the authentication function and confidentiality by a double use of the public-key scheme (Figure 9.4):, Z = E(PUb, E(PRa,X)), X = D(PUa, D(PRb,Z)), In this case, we begin as before by encrypting a message, using the sender’s private, key. This provides the digital signature. Next, we encrypt again, using the receiver’s, public key. The final ciphertext can be decrypted only by the intended receiver, who, alone has the matching private key. Thus, confidentiality is provided. The disadvantage of this approach is that the public-key algorithm, which is complex, must be, exercised four times rather than two in each communication., , Applications for Public-Key Cryptosystems, Before proceeding, we need to clarify one aspect of public-key cryptosystems that, is otherwise likely to lead to confusion. Public-key systems are characterized by the, use of a cryptographic algorithm with two keys, one held private and one available, publicly. Depending on the application, the sender uses either the sender’s private, key or the receiver’s public key, or both, to perform some type of cryptographic, , Source A, , Message, source, , X, , Encryption, algorithm, , Destination B, , Y, , Encryption, algorithm, , PUb, , Z, , Decryption, algorithm, , PRb, Ke y pair, source, , PRa, , Y, , PUa, , Key pair, source, , Figure 9.4 Public-Key Cryptosystem: Authentication and Secrecy, , Decryption, algorithm, , X, , Message, dest.
Page 293 :
292, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , function. In broad terms, we can classify the use of public-key cryptosystems into, three categories, ■, , ■, , ■, , Encryption/decryption: The sender encrypts a message with the recipient’s, public key, and the recipient decrypts the message with the recipient’s private, key., Digital signature: The sender “signs” a message with its private key. Signing, is achieved by a cryptographic algorithm applied to the message or to a small, block of data that is a function of the message., Key exchange: Two sides cooperate to exchange a session key, which is a secret, key for symmetric encryption generated for use for a particular transaction (or, session) and valid for a short period of time. Several different approaches are, possible, involving the private key(s) of one or both parties; this is discussed in, Chapter 10., , Some algorithms are suitable for all three applications, whereas others can be, used only for one or two of these applications. Table 9.3 indicates the applications, supported by the algorithms discussed in this book., , Requirements for Public-Key Cryptography, The cryptosystem illustrated in Figures 9.2 through 9.4 depends on a cryptographic, algorithm based on two related keys. Diffie and Hellman postulated this system, without demonstrating that such algorithms exist. However, they did lay out the, conditions that such algorithms must fulfill [DIFF76b]., 1. It is computationally easy for a party B to generate a key pair (public key PUb,, private key PRb)., 2. It is computationally easy for a sender A, knowing the public key and the message to be encrypted, M, to generate the corresponding ciphertext:, C = E(PUb, M), 3. It is computationally easy for the receiver B to decrypt the resulting ciphertext, using the private key to recover the original message:, M = D(PRb, C) = D[PRb, E(PUb, M)], 4. It is computationally infeasible for an adversary, knowing the public key, PUb,, to determine the private key, PRb., , Table 9.3 Applications for Public-Key Cryptosystems, Algorithm, , Encryption/Decryption, , Digital Signature, , Key Exchange, Yes, , RSA, , Yes, , Yes, , Elliptic Curve, , Yes, , Yes, , Yes, , Diffie–Hellman, , No, , No, , Yes, , DSS, , No, , Yes, , No
Page 294 :
9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS, , 293, , 5. It is computationally infeasible for an adversary, knowing the public key, PUb,, and a ciphertext, C, to recover the original message, M., We can add a sixth requirement that, although useful, is not necessary for all, public-key applications:, 6. The two keys can be applied in either order:, M = D[PUb, E(PRb, M)] = D[PRb, E(PUb, M)], These are formidable requirements, as evidenced by the fact that only a few, algorithms (RSA, elliptic curve cryptography, Diffie–Hellman, DSS) have received, widespread acceptance in the several decades since the concept of public-key cryptography was proposed., Before elaborating on why the requirements are so formidable, let us first recast them. The requirements boil down to the need for a trap-door one-way function. A one-way function3 is one that maps a domain into a range such that every, function value has a unique inverse, with the condition that the calculation of the, function is easy, whereas the calculation of the inverse is infeasible:, Y = f(X), easy, -1, X = f (Y) infeasible, Generally, easy is defined to mean a problem that can be solved in polynomial, time as a function of input length. Thus, if the length of the input is n bits, then the, time to compute the function is proportional to na, where a is a fixed constant. Such, algorithms are said to belong to the class P. The term infeasible is a much fuzzier, concept. In general, we can say a problem is infeasible if the effort to solve it grows, faster than polynomial time as a function of input size. For example, if the length, of the input is n bits and the time to compute the function is proportional to 2n,, the problem is considered infeasible. Unfortunately, it is difficult to determine if a, particular algorithm exhibits this complexity. Furthermore, traditional notions of, computational complexity focus on the worst-case or average-case complexity of, an algorithm. These measures are inadequate for cryptography, which requires that, it be infeasible to invert a function for virtually all inputs, not for the worst case or, even average case. A brief introduction to some of these concepts is provided in, Appendix W., We now turn to the definition of a trap-door one-way function, which is easy, to calculate in one direction and infeasible to calculate in the other direction unless certain additional information is known. With the additional information the, inverse can be calculated in polynomial time. We can summarize as follows: A trapdoor one-way function is a family of invertible functions f k, such that, Y = f k(X) easy, if k and X are known, X = f k-1(Y) easy, if k and Y are known, X = f k-1(Y) infeasible, if Y is known but k is not known, 3, Not to be confused with a one-way hash function, which takes an arbitrarily large data field as its, argument and maps it to a fixed output. Such functions are used for authentication (see Chapter 11).
Page 295 :
294, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , Thus, the development of a practical public-key scheme depends on discovery of a, suitable trap-door one-way function., , Public-Key Cryptanalysis, As with symmetric encryption, a public-key encryption scheme is vulnerable to a, brute-force attack. The countermeasure is the same: Use large keys. However, there, is a tradeoff to be considered. Public-key systems depend on the use of some sort of, invertible mathematical function. The complexity of calculating these functions may, not scale linearly with the number of bits in the key but grow more rapidly than that., Thus, the key size must be large enough to make brute-force attack impractical but, small enough for practical encryption and decryption. In practice, the key sizes that, have been proposed do make brute-force attack impractical but result in encryption/decryption speeds that are too slow for general-purpose use. Instead, as was, mentioned earlier, public-key encryption is currently confined to key management, and signature applications., Another form of attack is to find some way to compute the private key given, the public key. To date, it has not been mathematically proven that this form of attack is infeasible for a particular public-key algorithm. Thus, any given algorithm,, including the widely used RSA algorithm, is suspect. The history of cryptanalysis, shows that a problem that seems insoluble from one perspective can be found to, have a solution if looked at in an entirely different way., Finally, there is a form of attack that is peculiar to public-key systems. This is,, in essence, a probable-message attack. Suppose, for example, that a message were, to be sent that consisted solely of a 56-bit DES key. An adversary could encrypt all, possible 56-bit DES keys using the public key and could discover the encrypted key, by matching the transmitted ciphertext. Thus, no matter how large the key size of the, public-key scheme, the attack is reduced to a brute-force attack on a 56-bit key. This, attack can be thwarted by appending some random bits to such simple messages., , 9.2 THE RSA ALGORITHM, The pioneering paper by Diffie and Hellman [DIFF76b] introduced a new approach, to cryptography and, in effect, challenged cryptologists to come up with a cryptographic algorithm that met the requirements for public-key systems. A number of, algorithms have been proposed for public-key cryptography. Some of these, though, initially promising, turned out to be breakable.4, One of the first successful responses to the challenge was developed in 1977, by Ron Rivest, Adi Shamir, and Len Adleman at MIT and first published in 1978, [RIVE78].5 The Rivest-Shamir-Adleman (RSA) scheme has since that time reigned, supreme as the most widely accepted and implemented general-purpose approach, to public-key encryption., 4, , The most famous of the fallen contenders is the trapdoor knapsack proposed by Ralph Merkle. We, describe this in Appendix J., 5, Apparently, the first workable public-key system for encryption/decryption was put forward by Clifford, Cocks of Britain’s CESG in 1973 [COCK73]; Cocks’ method is virtually identical to RSA.
Page 296 :
9.2 / THE RSA ALGORITHM, , 295, , The RSA scheme is a cipher in which the plaintext and ciphertext are integers, between 0 and n - 1 for some n. A typical size for n is 1024 bits, or 309 decimal, digits. That is, n is less than 21024. We examine RSA in this section in some detail,, beginning with an explanation of the algorithm. Then we examine some of the computational and cryptanalytical implications of RSA., , Description of the Algorithm, RSA makes use of an expression with exponentials. Plaintext is encrypted in blocks,, with each block having a binary value less than some number n. That is, the block, size must be less than or equal to log 2(n) + 1; in practice, the block size is i bits,, where 2i 6 n … 2i + 1. Encryption and decryption are of the following form, for, some plaintext block M and ciphertext block C., C = Me mod n, M = C d mod n = (Me)d mod n = Med mod n, Both sender and receiver must know the value of n. The sender knows, the value of e, and only the receiver knows the value of d. Thus, this is a publickey encryption algorithm with a public key of PU = {e, n} and a private key of, PR = {d, n}. For this algorithm to be satisfactory for public-key encryption, the following requirements must be met., 1. It is possible to find values of e, d, and n such that Med mod n = M for all M 6 n., 2. It is relatively easy to calculate Me mod n and C d mod n for all values of M 6 n., 3. It is infeasible to determine d given e and n., For now, we focus on the first requirement and consider the other questions, later. We need to find a relationship of the form, Med mod n = M, The preceding relationship holds if e and d are multiplicative inverses modulo f(n),, where f(n) is the Euler totient function. It is shown in Chapter 2 that for p, q prime,, f(pq) = (p - 1)(q - 1). The relationship between e and d can be expressed as, ed mod f(n) = 1, , (9.1), , This is equivalent to saying, ed K 1 mod f(n), d K e -1 mod f(n), That is, e and d are multiplicative inverses mod f(n). Note that, according to the, rules of modular arithmetic, this is true only if d (and therefore e) is relatively, prime to f(n). Equivalently, gcd(f(n), d) = 1. See Appendix R for a proof that, Equation (9.1) satisfies the requirement for RSA., We are now ready to state the RSA scheme. The ingredients are the following:, p, q, two prime numbers, n = pq, e, with gcd(f(n), e) = 1; 1 6 e 6 f(n), d K e -1 (mod f(n)), , (private, chosen), (public, calculated), (public, chosen), (private, calculated)
Page 297 :
296, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , The private key consists of {d, n} and the public key consists of {e, n}. Suppose, that user A has published its public key and that user B wishes to send the message, M to A. Then B calculates C = Me mod n and transmits C. On receipt of this ciphertext, user A decrypts by calculating M = C d mod n., Figure 9.5 summarizes the RSA algorithm. It corresponds to Figure 9.1a: Alice, generates a public/private key pair; Bob encrypts using Alice’s public key; and Alice, decrypts using her private key. An example from [SING99] is shown in Figure 9.6., For this example, the keys were generated as follows., Select two prime numbers, p = 17 and q = 11., Calculate n = pq = 17 * 11 = 187., Calculate f(n) = (p - 1)(q - 1) = 16 * 10 = 160., Select e such that e is relatively prime to f(n) = 160 and less than f(n); we, choose e = 7., 5. Determine d such that de K 1 (mod 160) and d 6 160. The correct value is, d = 23, because 23 * 7 = 161 = (1 * 160) + 1; d can be calculated using, the extended Euclid’s algorithm (Chapter 2)., 1., 2., 3., 4., , The resulting keys are public key PU = {7, 187} and private key PR = {23, 187}., The example shows the use of these keys for a plaintext input of M = 88. For, encryption, we need to calculate C = 887 mod 187. Exploiting the properties of, modular arithmetic, we can do this as follows., 887 mod 187 = [(884 mod 187) * (882 mod 187), * (881 mod 187)] mod 187, 881 mod 187 = 88, 882 mod 187 = 7744 mod 187 = 77, 884 mod 187 = 59,969,536 mod 187 = 132, 887 mod 187 = (88 * 77 * 132) mod 187 = 894,432 mod 187 = 11, For decryption, we calculate M = 1123 mod 187:, 1123 mod 187 = [(111 mod 187) * (112 mod 187) * (114 mod 187), * (118 mod 187) * (118 mod 187)] mod 187, 111 mod 187 = 11, 112 mod 187 = 121, 114 mod 187 = 14,641 mod 187 = 55, 118 mod 187 = 214,358,881 mod 187 = 33, 1123 mod 187 = (11 * 121 * 55 * 33 * 33) mod 187, = 79,720,245 mod 187 = 88, We now look at an example from [HELL79], which shows the use of RSA to, process multiple blocks of data. In this simple example, the plaintext is an alphanumeric string. Each plaintext symbol is assigned a unique code of two decimal
Page 298 :
9.2 / THE RSA ALGORITHM, , 297, , Key Generation by Alice, p and q both prime, p ≠ q, , Select p, q, Calculate n = p * q, Calcuate f(n) = (p - 1)(q - 1), , gcd (f(n), e) = 1; 1 6 e 6 f(n), , Select integer e, , d K e -1 (mod f(n)), , Calculate d, Public key, , PU = {e, n}, , Private key, , PR = {d, n}, Encryption by Bob with Alice’s Public Key, , Plaintext:, , M 6 n, , Ciphertext:, , C = Me mod n, Decryption by Alice with Alice’s Public Key, , Ciphertext:, , C, , Plaintext:, , M = C d mod n, , Figure 9.5 The RSA Algorithm, Decryption, , Encryption, Plaintext, 88, , 7, , 88 mod 187 = 11, , Ciphertext, 11, , PU = 7, 187, , Figure 9.6, , 11, , 23, , mod 187 = 88, , Plaintext, 88, , PR ⫽ 23, 187, , Example of RSA Algorithm, , digits (e.g., a = 00, A = 26).6 A plaintext block consists of four decimal digits, or, two alphanumeric characters. Figure 9.7a illustrates the sequence of events for the, encryption of multiple blocks, and Figure 9.7b gives a specific example. The circled, numbers indicate the order in which operations are performed., , Computational Aspects, We now turn to the issue of the complexity of the computation required to use, RSA. There are actually two issues to consider: encryption/decryption and key, generation. Let us look first at the process of encryption and decryption and then, consider key generation., 6, , The complete mapping of alphanumeric characters to decimal digits is at box.com/Crypto7e in the document RSAexample.pdf.
Page 299 :
298, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, Sender, , Sender, , 3, , 3, Plaintext P, , How_are_you?, , Decimal string, , 33 14 22 62 00 17 04 62 24 14 20 66, , 4, , 4, , Blocks of numbers, P1, P2,, , P1 = 3314 P2 = 2262 P3 = 0017, P4 = 0462 P5 = 2414 P6 = 2066, , 5, , 5, Ciphertext C, , 2, , 2, , C1 = P1e mod n, C2 = P2e mod n, , Public key, e, n, , C1 = 331411 mod 11023 = 10260, C2 = 226211 mod 11023 = 9489, C3 = 1711 mod 11023 = 1782, C4 = 46211 mod 11023 = 727, C5 = 241411 mod 11023 = 10032, C6 = 206611 mod 11023 = 2253, , e = 11, n = 11023, , n = pq, , 11023 = 73 151, , Transmit, , 6, Private key, d, n, , 1, , Transmit, , 6, , 7, , d = e–1 mod f(n), f(n) = (p – 1)(q – 1), n = pq, , 7, , d = 5891, n = 11023, , Recovered, decimal text, P1 = C1d mod n, P2 = C2d mod n, , 1, , 5891 = 11–1 mod 10800, 10800 = (73 – 1)(151 – 1), 11023 = 73 51, , P1 = 102605891 mod 11023 = 3314, P2 = 94895891 mod 11023 = 2262, P3 = 17825891 mod 11023 = 0017, P4 = 7275891 mod 11023 = 0462, P5 = 100325891 mod 11023 = 2414, P6 = 22535891 mod 11023 = 2066, , e = 11, p = 73, q = 151, , e, p, q, , Random number, generator, , Receiver, , (a) General approach, , Random number, generator, , Receiver, , (b) Example, , Figure 9.7 RSA Processing of Multiple Blocks, , EXPONENTIATION IN MODULAR ARITHMETIC Both encryption and decryption in RSA, involve raising an integer to an integer power, mod n. If the exponentiation is done, over the integers and then reduced modulo n, the intermediate values would be, gargantuan. Fortunately, as the preceding example shows, we can make use of a, property of modular arithmetic:, [(a mod n) * (b mod n)] mod n = (a * b) mod n, Thus, we can reduce intermediate results modulo n. This makes the calculation, practical., Another consideration is the efficiency of exponentiation, because with RSA,, we are dealing with potentially large exponents. To see how efficiency might be increased, consider that we wish to compute x16. A straightforward approach requires, 15 multiplications:, x16 = x * x * x * x * x * x * x * x * x * x * x * x * x * x * x * x, , Hiva-Network.Com
Page 300 :
9.2 / THE RSA ALGORITHM, , 299, , However, we can achieve the same final result with only four multiplications if we, repeatedly take the square of each partial result, successively forming (x2, x4, x8, x16)., As another example, suppose we wish to calculate x11 mod n for some integers x, and n. Observe that x11 = x1 + 2 + 8 = (x)(x2)(x8). In this case, we compute x mod n,, x2 mod n, x4 mod n, and x8 mod n and then calculate [(x mod n) * (x2 mod n) *, (x8 mod n)] mod n., More generally, suppose we wish to find the value ab mod n with a, b, and m, positive integers. If we express b as a binary number bkbk - 1 c b0, then we have, b = a 2i, bi ≠ 0, , Therefore,, , ab = a, , ¢, , Σ2i, bi ≠ 0, , ≤, , i, , = q a(2 ), bi ≠ 0, , i, , i, , ab mod n = J q a(2 ) R mod n = ¢ q Ja(2 ) mod n R ≤ mod n, bi ≠ 0, , bi ≠ 0, , We can therefore develop the algorithm7 for computing ab mod n, shown in, Figure 9.8. Table 9.4 shows an example of the execution of this algorithm. Note that, the variable c is not needed; it is included for explanatory purposes. The final value, of c is the value of the exponent., EFFICIENT OPERATION USING THE PUBLIC KEY To speed up the operation of the, RSA algorithm using the public key, a specific choice of e is usually made. The most, common choice is 65537 (216 + 1); two other popular choices are 3 and 17. Each of, these choices has only two 1 bits, so the number of multiplications required to perform exponentiation is minimized., c, , 0; f, , for i, do, , if, , 1, , k downto 0, c, , 2 × c, , f, , (f × f) mod n, , bi = 1, then c, f, , c + 1, (f × a) mod n, , return f, Note: The integer b is expressed as a, binary number bkbk - 1c b0., , Figure 9.8 Algorithm for Computing ab mod n, 7, , The algorithm has a long history; this particular pseudocode expression is from [CORM09].
Page 301 :
300, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, Table 9.4 Result of the Fast Modular Exponentiation Algorithm for ab mod n, where a = 7,, b = 560 = 1000110000, and n = 561, i, , 9, , 8, , 7, , 6, , 5, , 4, , 3, , 2, , 1, , 0, , bi, c, f, , 1, 1, 7, , 0, 2, 49, , 0, 4, 157, , 0, 8, 526, , 1, 17, 160, , 1, 35, 241, , 0, 70, 298, , 0, 140, 166, , 0, 280, 67, , 0, 560, 1, , However, with a very small public key, such as e = 3, RSA becomes vulnerable to a simple attack. Suppose we have three different RSA users who all use, the value e = 3 but have unique values of n, namely (n1, n2, n3). If user A sends, the same encrypted message M to all three users, then the three ciphertexts are, C1 = M3 mod n1, C2 = M3 mod n2, and C3 = M3 mod n3. It is likely that n1, n2,, and n3 are pairwise relatively prime. Therefore, one can use the Chinese remainder, theorem (CRT) to compute M3 mod (n1n2n3). By the rules of the RSA algorithm,, M is less than each of the ni; therefore M3 6 n1n2n3. Accordingly, the attacker need, only compute the cube root of M3. This attack can be countered by adding a unique, pseudorandom bit string as padding to each instance of M to be encrypted. This approach is discussed subsequently., The reader may have noted that the definition of the RSA algorithm, (Figure 9.5) requires that during key generation the user selects a value of e that is, relatively prime to f(n). Thus, if a value of e is selected first and the primes p and q, are generated, it may turn out that gcd(f(n), e) ≠ 1. In that case, the user must, reject the p, q values and generate a new p, q pair., EFFICIENT OPERATION USING THE PRIVATE KEY We cannot similarly choose a small, constant value of d for efficient operation. A small value of d is vulnerable to a, brute-force attack and to other forms of cryptanalysis [WIEN90]. However, there, is a way to speed up computation using the CRT. We wish to compute the value, M = C d mod n. Let us define the following intermediate results:, Vp = C d mod p Vq = C d mod q, Following the CRT using Equation (8.8), define the quantities, Xp = q * (q -1 mod p) Xq = p * (p-1 mod q), The CRT then shows, using Equation (8.9), that, M = (VpXp + VqXq) mod n, Furthermore, we can simplify the calculation of Vp and Vq using Fermat’s, theorem, which states that ap - 1 K 1 (mod p) if p and a are relatively prime. Some, thought should convince you that the following are valid., Vp = C d mod p = C d mod(p - 1) mod p Vq = C d mod q = C d mod(q - 1) mod q
Page 302 :
9.2 / THE RSA ALGORITHM, , 301, , The quantities d mod (p - 1) and d mod (q - 1) can be precalculated. The, end result is that the calculation is approximately four times as fast as evaluating, M = C d mod n directly [BONE02]., KEY GENERATION Before the application of the public-key cryptosystem, each participant must generate a pair of keys. This involves the following tasks., ■, ■, , Determining two prime numbers, p and q., Selecting either e or d and calculating the other., , First, consider the selection of p and q. Because the value of n = pq will be, known to any potential adversary, in order to prevent the discovery of p and q, by exhaustive methods, these primes must be chosen from a sufficiently large set, (i.e., p and q must be large numbers). On the other hand, the method used for finding large primes must be reasonably efficient., At present, there are no useful techniques that yield arbitrarily large primes,, so some other means of tackling the problem is needed. The procedure that is generally used is to pick at random an odd number of the desired order of magnitude, and test whether that number is prime. If not, pick successive random numbers until, one is found that tests prime., A variety of tests for primality have been developed (e.g., see [KNUT98] for, a description of a number of such tests). Almost invariably, the tests are probabilistic. That is, the test will merely determine that a given integer is probably prime., Despite this lack of certainty, these tests can be run in such a way as to make the, probability as close to 1.0 as desired. As an example, one of the more efficient, and popular algorithms, the Miller–Rabin algorithm, is described in Chapter 2., With this algorithm and most such algorithms, the procedure for testing whether, a given integer n is prime is to perform some calculation that involves n and a, randomly chosen integer a. If n “fails” the test, then n is not prime. If n “passes”, the test, then n may be prime or nonprime. If n passes many such tests with many, different randomly chosen values for a, then we can have high confidence that n, is, in fact, prime., In summary, the procedure for picking a prime number is as follows., 1. Pick an odd integer n at random (e.g., using a pseudorandom number, generator)., 2. Pick an integer a 6 n at random., 3. Perform the probabilistic primality test, such as Miller–Rabin, with a as a, parameter. If n fails the test, reject the value n and go to step 1., 4. If n has passed a sufficient number of tests, accept n; otherwise, go to step 2., This is a somewhat tedious procedure. However, remember that this process is performed relatively infrequently: only when a new pair (PU, PR) is needed., It is worth noting how many numbers are likely to be rejected before a, prime number is found. A result from number theory, known as the prime number, theorem, states that the primes near N are spaced on the average one every
Page 303 :
302, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , ln (N) integers. Thus, on average, one would have to test on the order of ln(N), integers before a prime is found. Actually, because all even integers can be immediately rejected, the correct figure is ln(N)/2. For example, if a prime on the, order of magnitude of 2200 were sought, then about ln(2200)/2 = 70 trials would be, needed to find a prime., Having determined prime numbers p and q, the process of key generation is, completed by selecting a value of e and calculating d or, alternatively, selecting a, value of d and calculating e. Assuming the former, then we need to select an e such, that gcd(f(n), e) = 1 and then calculate d K e -1 (mod f(n)). Fortunately, there is, a single algorithm that will, at the same time, calculate the greatest common divisor of two integers and, if the gcd is 1, determine the inverse of one of the integers, modulo the other. The algorithm, referred to as the extended Euclid’s algorithm,, is explained in Chapter 2. Thus, the procedure is to generate a series of random, numbers, testing each against f(n) until a number relatively prime to f(n) is found., Again, we can ask the question: How many random numbers must we test to find, a usable number, that is, a number relatively prime to f(n)? It can be shown easily, that the probability that two random numbers are relatively prime is about 0.6; thus,, very few tests would be needed to find a suitable integer (see Problem 2.18)., , The Security of RSA, Five possible approaches to attacking the RSA algorithm are, ■, ■, ■, ■, ■, , Brute force: This involves trying all possible private keys., Mathematical attacks: There are several approaches, all equivalent in effort to, factoring the product of two primes., Timing attacks: These depend on the running time of the decryption algorithm., Hardware fault-based attack: This involves inducing hardware faults in the, processor that is generating digital signatures., Chosen ciphertext attacks: This type of attack exploits properties of the RSA, algorithm., , The defense against the brute-force approach is the same for RSA as for other, cryptosystems, namely, to use a large key space. Thus, the larger the number of bits, in d, the better. However, because the calculations involved, both in key generation, and in encryption/decryption, are complex, the larger the size of the key, the slower, the system will run., In this subsection, we provide an overview of mathematical and timing attacks., THE FACTORING PROBLEM We can identify three approaches to attacking RSA, mathematically., 1. Factor n into its two prime factors. This enables calculation of f(n) =, (p - 1) * (q - 1), which in turn enables determination of d K e -1 (mod f(n))., 2. Determine f(n) directly, without first determining p and q. Again, this enables, determination of d K e -1 (mod f(n))., 3. Determine d directly, without first determining f(n).
Page 304 :
9.2 / THE RSA ALGORITHM, , 303, , Most discussions of the cryptanalysis of RSA have focused on the task of, factoring n into its two prime factors. Determining f(n) given n is equivalent to, factoring n [RIBE96]. With presently known algorithms, determining d given, e and n appears to be at least as time-consuming as the factoring problem [KALI95]., Hence, we can use factoring performance as a benchmark against which to evaluate, the security of RSA., For a large n with large prime factors, factoring is a hard problem, but it is not, as hard as it used to be. A striking illustration of this is the following. In 1977, the, three inventors of RSA dared Scientific American readers to decode a cipher they, printed in Martin Gardner’s “Mathematical Games” column [GARD77]. They offered a $100 reward for the return of a plaintext sentence, an event they predicted, might not occur for some 40 quadrillion years. In April of 1994, a group working, over the Internet claimed the prize after only eight months of work [LEUT94]. This, challenge used a public key size (length of n) of 129 decimal digits, or around 428, bits. In the meantime, just as they had done for DES, RSA Laboratories had issued, challenges for the RSA cipher with key sizes of 100, 110, 120, and so on, digits. The, latest challenge to be met is the RSA-768 challenge with a key length of 232 decimal, digits, or 768 bits. Table 9.5 shows the results., A striking fact about the progress reflected in Table 9.5 concerns the method, used. Until the mid-1990s, factoring attacks were made using an approach known, as the quadratic sieve. The attack on RSA-130 used a newer algorithm, the generalized number field sieve (GNFS), and was able to factor a larger number than, RSA-129 at only 20% of the computing effort., The threat to larger key sizes is twofold: the continuing increase in computing, power and the continuing refinement of factoring algorithms. We have seen that, the move to a different algorithm resulted in a tremendous speedup. We can expect, further refinements in the GNFS, and the use of an even better algorithm is also, a possibility. In fact, a related algorithm, the special number field sieve (SNFS),, Table 9.5, , Progress in RSA Factorization, , Number of Decimal Digits, , Number of Bits, , Date Achieved, , 100, , 332, , April 1991, , 110, , 365, , April 1992, , 120, , 398, , June 1993, , 129, , 428, , April 1994, , 130, , 431, , April 1996, , 140, , 465, , February 1999, , 155, , 512, , August 1999, , 160, , 530, , April 2003, , 174, , 576, , December 2003, , 200, , 663, , May 2005, , 193, , 640, , November 2005, , 232, , 768, , December 2009
Page 305 :
CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , can factor numbers with a specialized form considerably faster than the generalized, number field sieve. Figure 9.9 compares the performance of the two algorithms. It is, reasonable to expect a breakthrough that would enable a general factoring performance in about the same time as SNFS, or even better [ODLY95]. Thus, we need, to be careful in choosing a key size for RSA. The team that produced the 768-bit, factorization [KLEI10] observed that factoring a 1024-bit RSA modulus would be, about a thousand times harder than factoring a 768-bit modulus, and a 768-bit RSA, modulus is several thousands times harder to factor than a 512-bit one. Based on the, amount of time between the 512-bit and 768-bit factorization successes, the team, felt it to be reasonable to expect that the 1024-bit RSA moduli could be factored, well within the next decade by a similar academic effort. Thus, they recommended, phasing out usage of 1024-bit RSA within the next few years (from 2010)., , 1022, , 1020, , 1018, , 1016, General number, field sieve, MIPS-years needed to factor, , 304, , 10, , 14, , 1012, , 1010, , 108, Special number, field sieve, 106, , 104, , 102, , 100, , 600, , 800, , 1000, , Figure 9.9 MIPS-years Needed to Factor, , 1200, Bits, , 1400, , 1600, , 1800, , 2000
Page 306 :
9.2 / THE RSA ALGORITHM, , 305, , In addition to specifying the size of n, a number of other constraints have been, suggested by researchers. To avoid values of n that may be factored more easily, the, algorithm’s inventors suggest the following constraints on p and q., 1. p and q should differ in length by only a few digits. Thus, for a 1024-bit key, (309 decimal digits), both p and q should be on the order of magnitude of, 1075 to 10100., 2. Both (p - 1) and (q - 1) should contain a large prime factor., 3. gcd(p - 1, q - 1) should be small., In addition, it has been demonstrated that if e 6 n and d 6 n1/4, then d can be easily, determined [WIEN90]., TIMING ATTACKS If one needed yet another lesson about how difficult it is to assess, the security of a cryptographic algorithm, the appearance of timing attacks provides, a stunning one. Paul Kocher, a cryptographic consultant, demonstrated that a, snooper can determine a private key by keeping track of how long a computer takes, to decipher messages [KOCH96, KALI96b]. Timing attacks are applicable not just, to RSA, but to other public-key cryptography systems. This attack is alarming for, two reasons: It comes from a completely unexpected direction, and it is a ciphertextonly attack., A timing attack is somewhat analogous to a burglar guessing the combination of a safe by observing how long it takes for someone to turn the dial, from number to number. We can explain the attack using the modular exponentiation algorithm of Figure 9.8, but the attack can be adapted to work with, any implementation that does not run in fixed time. In this algorithm, modular, exponentiation is accomplished bit by bit, with one modular multiplication performed at each iteration and an additional modular multiplication performed, for each 1 bit., As Kocher points out in his paper, the attack is simplest to understand in an, extreme case. Suppose the target system uses a modular multiplication function that, is very fast in almost all cases but in a few cases takes much more time than an entire, average modular exponentiation. The attack proceeds bit-by-bit starting with the, leftmost bit, bk. Suppose that the first j bits are known (to obtain the entire exponent,, start with j = 0 and repeat the attack until the entire exponent is known). For a, given ciphertext, the attacker can complete the first j iterations of the for loop. The, operation of the subsequent step depends on the unknown exponent bit. If the bit, is set, d d (d * a) mod n will be executed. For a few values of a and d, the modular multiplication will be extremely slow, and the attacker knows which these are., Therefore, if the observed time to execute the decryption algorithm is always slow, when this particular iteration is slow with a 1 bit, then this bit is assumed to be 1., If a number of observed execution times for the entire algorithm are fast, then this, bit is assumed to be 0., In practice, modular exponentiation implementations do not have such extreme timing variations, in which the execution time of a single iteration can exceed the mean execution time of the entire algorithm. Nevertheless, there is enough, variation to make this attack practical. For details, see [KOCH96].
Page 307 :
306, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , Although the timing attack is a serious threat, there are simple countermeasures that can be used, including the following., ■, , ■, , ■, , Constant exponentiation time: Ensure that all exponentiations take the same, amount of time before returning a result. This is a simple fix but does degrade, performance., Random delay: Better performance could be achieved by adding a random, delay to the exponentiation algorithm to confuse the timing attack. Kocher, points out that if defenders don’t add enough noise, attackers could still succeed by collecting additional measurements to compensate for the random, delays., Blinding: Multiply the ciphertext by a random number before performing exponentiation. This process prevents the attacker from knowing what ciphertext bits are being processed inside the computer and therefore prevents the, bit-by-bit analysis essential to the timing attack., , RSA Data Security incorporates a blinding feature into some of its products., The private-key operation M = Cd mod n is implemented as follows., 1., 2., 3., 4., , Generate a secret random number r between 0 and n - 1., Compute C′ = C(r e) mod n, where e is the public exponent., Compute M′ = (C′)d mod n with the ordinary RSA implementation., Compute M = M′r -1 mod n. In this equation, r -1 is the multiplicative inverse, of r mod n; see Chapter 2 for a discussion of this concept. It can be demonstrated that this is the correct result by observing that r ed mod n = r mod n., RSA Data Security reports a 2 to 10% performance penalty for blinding., , FAULT-BASED ATTACK Still another unorthodox approach to attacking RSA is reported in [PELL10]. The approach is an attack on a processor that is generating, RSA digital signatures. The attack induces faults in the signature computation by, reducing the power to the processor. The faults cause the software to produce invalid signatures, which can then be analyzed by the attacker to recover the private, key. The authors show how such an analysis can be done and then demonstrate it, by extracting a 1024-bit private RSA key in approximately 100 hours, using a commercially available microprocessor., The attack algorithm involves inducing single-bit errors and observing the results. The details are provided in [PELL10], which also references other proposed, hardware fault-based attacks against RSA., This attack, while worthy of consideration, does not appear to be a serious, threat to RSA. It requires that the attacker have physical access to the target machine and that the attacker is able to directly control the input power to the processor. Controlling the input power would for most hardware require more than, simply controlling the AC power, but would also involve the power supply control, hardware on the chip.
Page 308 :
9.2 / THE RSA ALGORITHM, , 307, , CHOSEN CIPHERTEXT ATTACK AND OPTIMAL ASYMMETRIC ENCRYPTION PADDING The, basic RSA algorithm is vulnerable to a chosen ciphertext attack (CCA). CCA is, defined as an attack in which the adversary chooses a number of ciphertexts and, is then given the corresponding plaintexts, decrypted with the target’s private key., Thus, the adversary could select a plaintext, encrypt it with the target’s public key,, and then be able to get the plaintext back by having it decrypted with the private, key. Clearly, this provides the adversary with no new information. Instead, the adversary exploits properties of RSA and selects blocks of data that, when processed, using the target’s private key, yield information needed for cryptanalysis., A simple example of a CCA against RSA takes advantage of the following, property of RSA:, E(PU, M1) * E(PU, M2) = E(PU, [M1 * M2]), , (9.2), , We can decrypt C = M mod n using a CCA as follows., e, , 1. Compute X = (C * 2e) mod n., 2. Submit X as a chosen ciphertext and receive back Y = Xd mod n., But now note that, X = (C mod n) * (2e mod n), = (Me mod n) * (2e mod n), = (2M)e mod n, Therefore, Y = (2M) mod n. From this, we can deduce M. To overcome this, simple attack, practical RSA-based cryptosystems randomly pad the plaintext prior, to encryption. This randomizes the ciphertext so that Equation (9.2) no longer, holds. However, more sophisticated CCAs are possible, and a simple padding with a, random value has been shown to be insufficient to provide the desired security. To, counter such attacks, RSA Security Inc., a leading RSA vendor and former holder, of the RSA patent, recommends modifying the plaintext using a procedure known, as optimal asymmetric encryption padding (OAEP). A full discussion of the threats, and OAEP are beyond our scope; see [POIN02] for an introduction and [BELL94], for a thorough analysis. Here, we simply summarize the OAEP procedure., Figure 9.10 depicts OAEP encryption. As a first step, the message M to be encrypted is padded. A set of optional parameters, P, is passed through a hash function, H.8 The output is then padded with zeros to get the desired length in the overall, data block (DB). Next, a random seed is generated and passed through another hash, function, called the mask generating function (MGF). The resulting hash value is bitby-bit XORed with DB to produce a maskedDB. The maskedDB is in turn passed, through the MGF to form a hash that is XORed with the seed to produce the maskedseed. The concatenation of the maskedseed and the maskedDB forms the encoded, message EM. Note that the EM includes the padded message, masked by the seed,, and the seed, masked by the maskedDB. The EM is then encrypted using RSA., 8, , A hash function maps a variable-length data block or message into a fixed-length value called a hash, code. Hash functions are discussed in depth in Chapter 11., , Hiva-Network.Com
Page 309 :
308, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, P, , Seed, , M, , H(P), , Padding, , DB, , MGF, , MaskedDB, , MGF, , Maskedseed, , EM, P = encoding parameters, M = message to be encoded, H = hash function, , Figure 9.10, , DB = data block, MGF = mask generating function, EM = encoded message, , Encryption Using Optimal Asymmetric, Encryption Padding (OAEP), , 9.3 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, chosen ciphertext attack, (CCA), digital signature, key exchange, one-way function, , optimal asymmetric encryption, padding (OAEP), private key, public key, public-key cryptography, , public-key cryptosystems, public-key encryption, RSA, timing attack, trap-door one-way function, , Review Questions, 9.1, 9.2, 9.3, , What is a public key certificate?, What are the roles of the public and private key?, What are three broad categories of applications of public-key cryptosystems?
Page 310 :
9.3 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 9.4, 9.5, 9.6, 9.7, , 309, , What requirements must a public-key cryptosystems fulfill to be a secure algorithm?, How can a probable-message attack be used for public-key cryptanalysis?, List the different approaches to attack the RSA algorithm., Describe the countermeasures to be used against the timing attack., , Problems, 9.1, , Prior to the discovery of any specific public-key schemes, such as RSA, an existence, proof was developed whose purpose was to demonstrate that public-key encryption is, possible in theory. Consider the functions f 1(x1) = z1; f 2(x2, y2) = z2; f 3(x3, y3) = z3,, where all values are integers with 1 … xi, yi, zi … N. Function f 1 can be represented, by a vector M1 of length N, in which the kth entry is the value of f 1(k). Similarly, f 2, and f 3 can be represented by N * N matrices M2 and M3. The intent is to represent, the encryption/decryption process by table lookups for tables with very large values, of N. Such tables would be impractically huge but could be constructed in principle., The scheme works as follows: Construct M1 with a random permutation of all integers between 1 and N; that is, each integer appears exactly once in M1. Construct M2, so that each row contains a random permutation of the first N integers. Finally, fill in, M3 to satisfy the following condition:, f 3 (f 2 (f 1 (k), p), k) = p, , for all k, p with 1 … k, p, … N, , To summarize,, 1. M1 takes an input k and produces an output x., 2. M2 takes inputs x and p giving output z., 3. M3 takes inputs z and k and produces p., The three tables, once constructed, are made public., a. It should be clear that it is possible to construct M3 to satisfy the preceding condition. As an example, fill in M3 for the following simple case:, 4, , 3, , 5, , 2, , 4, , 1, , 3, , 4, , 2, , 5, , 3, , 1, , M1 = 2, , 9.2, , 9.3, , M2 =, , 5, , 4, , 3, , 1, , 2, , 5, , 1, , 3, , 2, , 5, , 4, , 1, , 2, , 1, , 4, , 3, , 5, , M3 =, , Convention: The ith element of M1 corresponds to k = i. The ith row of M2 corresponds to x = i; the jth column of M2 corresponds to p = j. The ith row of M3, corresponds to z = i; the jth column of M3 corresponds to k = j., b. Describe the use of this set of tables to perform encryption and decryption between two users., c. Argue that this is a secure scheme., Perform encryption and decryption using the RSA algorithm, as in Figure 9.5, for the, following:, a. p = 3 ; q = 7 , e = 5 ; M = 1 0, b. p = 5 ; q = 1 3 , e = 5 ; M = 8, c. p = 7 ; q = 1 7 , e = 1 1 ; M = 1 1, d. p = 7 ; q = 1 3 , e = 1 1 ; M = 2, e. p = 1 7 ; q = 2 3 , e = 9 ; M = 7, Hint: Decryption is not as hard as you think; use some finesse., In a public-key system using RSA, you intercept the ciphertext C = 2 0 sent to a user, whose public key is e = 1 3 , n = 7 7 . What is the plaintext M?
Page 311 :
310, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, 9.4, , 9.5, 9.6, , 9.7, , 9.8, , 9.9, , 9.10, , 9.11, , In an RSA system, the public key of a given user is e = 6 5 , n = 2 8 8 1 . What is the, private key of this user? Hint: First use trial-and-error to determine p and q; then use, the extended Euclidean algorithm to find the multiplicative inverse of 31 modulo, f(n)., In using the RSA algorithm, if a small number of repeated encodings give back the, plaintext, what is the likely cause?, Suppose we have a set of blocks encoded with the RSA algorithm and we don’t have, the private key. Assume n = pq, e is the public key. Suppose also someone tells us, they know one of the plaintext blocks has a common factor with n. Does this help us, in any way?, In the RSA public-key encryption scheme, each user has a public key, e, and a private, key, d. Suppose Bob leaks his private key. Rather than generating a new modulus, he, decides to generate a new public and a new private key. Is this safe?, Suppose Bob uses the RSA cryptosystem with a very large modulus n for which the, factorization cannot be found in a reasonable amount of time. Suppose Alice sends, a message to Bob by representing each alphabetic character as an integer between, 0 and 25 (A S 0, c , Z S 25) and then encrypting each number separately using, RSA with large e and large n. Is this method secure? If not, describe the most efficient attack against this encryption method., Using a spreadsheet (such as Excel) or a calculator, perform the operations described, below. Document results of all intermediate modular multiplications. Determine a, number of modular multiplications per each major transformation (such as encryption, decryption, primality testing, etc.)., a. Test all odd numbers in the range from 215 to 223 for primality using the Miller–, Rabin test with base 2., b. Encrypt the message block M = 2 using RSA with the following parameters:, e = 23 and n = 233 * 241., c. Compute a private key (d, p, q) corresponding to the given above public key (e, n)., d. Perform the decryption of the obtained ciphertext, 1. without using the Chinese Remainder Theorem, and, 2. using the Chinese Remainder Theorem., Assume that you generate an authenticated and encrypted message by first applying the, RSA transformation determined by your private key, and then enciphering the message using recipient’s public key (note that you do NOT use hash function before the, first transformation). Will this scheme work correctly [i.e., give the possibility to reconstruct the original message at the recipient’s side, for all possible relations between the, sender’s modulus nS and the recipient’s modulus nR (nS 7 nR, nS 6 nR, nS = nR)]?, Explain your answer. In case your answer is “no,” how would you correct this scheme?, “I want to tell you, Holmes,” Dr. Watson’s voice was enthusiastic, “that your recent, activities in network security have increased my interest in cryptography. And just, yesterday I found a way to make one-time pad encryption practical.”, “Oh, really?” Holmes’ face lost its sleepy look., “Yes, Holmes. The idea is quite simple. For a given one-way function F, I generate a long pseudorandom sequence of elements by applying F to some standard sequence of arguments. The cryptanalyst is assumed to know F and the general nature, of the sequence, which may be as simple as S, S + 1, S + 2, c , but not secret S., And due to the one-way nature of F, no one is able to extract S given F(S + i) for, some i, thus even if he somehow obtains a certain segment of the sequence, he will, not be able to determine the rest.”, “I am afraid, Watson, that your proposal isn’t without flaws and at least it needs, some additional conditions to be satisfied by F. Let’s consider, for instance, the RSA, encryption function, that is F(M) = MK mod N, K is secret. This function is believed, to be one-way, but I wouldn’t recommend its use, for example, on the sequence, M = 2, 3, 4, 5, 6, . . . ”
Page 312 :
9.3 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 9.12, 9.13, , 9.14, , 9.15, , 311, , “But why, Holmes?” Dr. Watson apparently didn’t understand. “Why do you, think that the resulting sequence 2K mod N, 3K mod N, 4K mod N, . . . is not appropriate for one-time pad encryption if K is kept secret?”, “Because it is—at least partially—predictable, dear Watson, even if K is kept secret. You have said that the cryptanalyst is assumed to know F and the general nature, of the sequence. Now let’s assume that he will obtain somehow a short segment of the, output sequence. In crypto circles, this assumption is generally considered to be a viable one. And for this output sequence, knowledge of just the first two elements will, allow him to predict quite a lot of the next elements of the sequence, even if not all of, them, thus this sequence can’t be considered to be cryptographically strong. And with, the knowledge of a longer segment he could predict even more of the next elements, of the sequence. Look, knowing the general nature of the sequence and its first two, elements 2K mod N and 3K mod N, you can easily compute its following elements.”, Show how this can be done., Show how RSA can be represented by matrices M1, M2, and M3 of Problem 9.1., Consider the following scheme:, 1. Pick an odd number, E., 2. Pick two prime numbers, P and Q, where (P - 1)(Q - 1) - 1 is evenly divisible, by E., 3. Multiply P and Q to get N., (P - 1)(Q - 1)(E - 1) + 1, 4. Calculate D =, E, Is this scheme equivalent to RSA? Show why or why not., Consider the following scheme by which B encrypts a message for A., 1. A chooses two large primes P and Q that are also relatively prime to (P - 1), and (Q - 1)., 2. A publishes N = PQ as its public key., 3. A calculates P= and Q= such that PP= K 1 (mod Q - 1) and QQ= K 1 (mod P - 1)., 4. B encrypts message M as C = = MN mod N., =, 5. A finds M by solving M K C P (mod Q) and M K C Q (mod P)., a. Explain how this scheme works., b. How does it differ from RSA?, c. Is there any particular advantage to RSA compared to this scheme?, d. Show how this scheme can be represented by matrices M1, M2, and M3 of, Problem 9.1., “This is a very interesting case, Watson,” Holmes said. “The young man loves a girl,, and she loves him too. However, her father is a strange fellow who insists that his, would-be son-in-law must design a simple and secure protocol for an appropriate, public-key cryptosystem he could use in his company’s computer network. The young, man came up with the following protocol for communication between two parties., For example, user A wishing to send message M to user B: (messages exchanged are, in the format sender’s name, text, receiver’s name)”, 1. A sends B the following block: (A, E(PUb, [M, A]), B)., 2. B acknowledges receipt by sending to A the following block: (B, E(PUa, [M, B]), A)., “You can see that the protocol is really simple. But the girl’s father claims that the, young man has not satisfied his call for a simple protocol, because the proposal contains a certain redundancy and can be further simplified to the following:”, 1. A sends B the block: (A, E(PUb, M), B)., 2. B acknowledges receipt by sending to A the block: (B, E(PUa, M), A)., “On the basis of that, the girl’s father refuses to allow his daughter to marry the, young man, thus making them both unhappy. The young man was just here to ask, me for help.”
Page 313 :
312, , CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , 9.16, 9.17, , 9.18, , “Hmm, I don’t see how you can help him.” Watson was visibly unhappy with the, idea that the sympathetic young man has to lose his love., “Well, I think I could help. You know, Watson, redundancy is sometimes good to, ensure the security of protocol. Thus, the simplification the girl’s father has proposed, could make the new protocol vulnerable to an attack the original protocol was able, to resist,” mused Holmes. “Yes, it is so, Watson. Look, all an adversary needs is to, be one of the users of the network and to be able to intercept messages exchanged, between A and B. Being a user of the network, he has his own public encryption key, and is able to send his own messages to A or to B and to receive theirs. With the help, of the simplified protocol, he could then obtain message M user A has previously sent, to B using the following procedure:”, Complete the description., Use the fast exponentiation algorithm of Figure 9.8 to determine 6 4 7 2 mod 3415., Show the steps involved in the computation., Here is another realization of the fast exponentiation algorithm. Demonstrate that it, is equivalent to the one in Figure 9.8., 1. f d 1; T d a; E d b, 2. if odd(E) then f d f : T, 3. E d [ E/2 ], 4. T d T : T, 5. if E + 0 then goto 2, 6. output f, This problem illustrates a simple application of the chosen ciphertext attack. Bob, intercepts a ciphertext C intended for Alice and encrypted with Alice’s public key e., Bob wants to obtain the original message M = C d mod n. Bob chooses a random, value r less than n and computes, Z = r e mod n, X = ZC mod n, t = r -1 mod n, , 9.19, 9.20, , 9.21, 9.22, , Next, Bob gets Alice to authenticate (sign) X with her private key (as in Figure 9.3),, thereby decrypting X. Alice returns Y = Xd mod n. Show how Bob can use the information now available to him to determine M., Show the OAEP decoding operation used for decryption that corresponds to the, encoding operation of Figure 9.10., Improve on algorithm P1 in Appendix W., a. Develop an algorithm that requires 2n multiplications and n + 1 additions. Hint:, xi + 1 = xi * x., b. Develop an algorithm that requires only n + 1 multiplications and n + 1 additions. Hint: P(x) = a0 + x * q(x), where q(x) is a polynomial of degree (n - 1)., Note: The remaining problems concern the knapsack public-key algorithm described, in Appendix J., What items are in the knapsack in Figure F.1?, Perform encryption and decryption using the knapsack algorithm for the following:, a. a= = (1, 5, 7, 14); w = 11; m = 30; x = 1011, b. a= = (1, 2, 7, 12, 23, 38, 116, 248); w = 201; m = 457; x = 10101010, c. a= = (2, 4, 7, 15, 29); w = 36; m = 47; x = 10011, d. a= = (15, 92, 108, 279, 563, 1172, 2243, 4468); w = 2033; m = 8764; x = 10110011, n, , 9.23, , Why is it a requirement that m 7 a a=i?, 1=1
Page 314 :
CHAPTER, , Other Public-Key, Cryptosystems, 10.1 Diffie–Hellman Key Exchange, The Algorithm, Key Exchange Protocols, Man-in-the-Middle Attack, 10.2 Elgamal Cryptographic System, 10.3 Elliptic Curve Arithmetic, Abelian Groups, Elliptic Curves over Real Numbers, Elliptic Curves over Z p, Elliptic Curves over GF(2m), 10.4 Elliptic Curve Cryptography, Analog of Diffie–Hellman Key Exchange, Elliptic Curve Encryption/Decryption, Security of Elliptic Curve Cryptography, 10.5 Pseudorandom Number Generation Based on an Asymmetric Cipher, PRNG Based on RSA, PRNG Based on Elliptic Curve Cryptography, 10.6 Key Terms, Review Questions, and Problems, , 313
Page 315 :
314, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, ◆, , Define Diffie–Hellman key exchange., Understand the man-in-the-middle attack., Present an overview of the Elgamal cryptographic system., Understand elliptic curve arithmetic., Present an overview of elliptic curve cryptography., Present two techniques for generating pseudorandom numbers using an, asymmetric cipher., , This chapter begins with a description of one of the earliest and simplest PKCS:, Diffie–Hellman key exchange. The chapter then looks at another important scheme,, the Elgamal PKCS. Next, we look at the increasingly important PKCS known as elliptic, curve cryptography. Finally, the use of public-key algorithms for pseudorandom number generation is examined., , 10.1 DIFFIE–HELLMAN KEY EXCHANGE, The first published public-key algorithm appeared in the seminal paper by Diffie, and Hellman that defined public-key cryptography [DIFF76b] and is generally referred to as Diffie–Hellman key exchange.1 A number of commercial products employ this key exchange technique., The purpose of the algorithm is to enable two users to securely exchange a, key that can then be used for subsequent symmetric encryption of messages. The, algorithm itself is limited to the exchange of secret values., The Diffie–Hellman algorithm depends for its effectiveness on the difficulty, of computing discrete logarithms. Briefly, we can define the discrete logarithm in, the following way. Recall from Chapter 2 that a primitive root of a prime number p, is one whose powers modulo p generate all the integers from 1 to p - 1. That is, if, a is a primitive root of the prime number p, then the numbers, a mod p, a2 mod p, c , ap - 1 mod p, are distinct and consist of the integers from 1 through p - 1 in some permutation., For any integer b and a primitive root a of prime number p, we can find a, unique exponent i such that, b K ai (mod p), 1, , where 0 … i … (p - 1), , Williamson of Britain’s CESG published the identical scheme a few months earlier in a classified document [WILL76] and claims to have discovered it several years prior to that; see [ELLI99] for a discussion.
Page 316 :
10.1 / DIFFIE–HELLMAN KEY EXCHANGE, , 315, , The exponent i is referred to as the discrete logarithm of b for the base a, mod p. We, express this value as dlog a,p(b). See Chapter 2 for an extended discussion of discrete, logarithms., , The Algorithm, Figure 10.1 summarizes the Diffie–Hellman key exchange algorithm. For this, scheme, there are two publicly known numbers: a prime number q and an integer a that is a primitive root of q. Suppose the users A and B wish to create a, shared key., User A selects a random integer XA 6 q and computes YA = aXA mod q., Similarly, user B independently selects a random integer XB 6 q and computes, YB = aXB mod q. Each side keeps the X value private and makes the Y value available publicly to the other side. Thus, XA is A’s private key and YA is A’s corresponding public key, and similarly for B. User A computes the key as K = (YB)XA mod q, and user B computes the key as K = (YA)XB mod q. These two calculations produce, identical results:, , Alice, , Bob, , Alice and Bob share a, prime number q and an, integer A, such that A < q and, A is a primitive root of q, , Alice and Bob share a, prime number q and an, integer A, such that A < q and, A is a primitive root of q, , Alice generates a private, key XA such that XA < q, , Bob generates a private, key XB such that XB < q, , Alice calculates a public, key YA = AXA mod q, , YA, , YB, , Bob calculates a public, key YB = AXB mod q, , Alice receives Bob’s, public key YB in plaintext, , Bob receives Alice’s, public key YA in plaintext, , Alice calculates shared, secret key K = (YB)XA mod q, , Bob calculates shared, secret key K = (YA)XB mod q, , Figure 10.1 The Diffie–Hellman Key Exchange
Page 317 :
316, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , K = (YB)XA mod q, = (aXB mod q)XA mod q, = (aXB)XA mod q, = a, , XBXA, , = (a ), , mod q, , XA XB, , = (a, , XA, , by the rules of modular arithmetic, , mod q, , mod q)XB mod q, , = (YA)XB mod q, The result is that the two sides have exchanged a secret value. Typically, this, secret value is used as shared symmetric secret key. Now consider an adversary who, can observe the key exchange and wishes to determine the secret key K. Because, XA and XB are private, an adversary only has the following ingredients to work with:, q, a, YA, and YB. Thus, the adversary is forced to take a discrete logarithm to determine the key. For example, to determine the private key of user B, an adversary, must compute, XB = dlog a,q(YB), The adversary can then calculate the key K in the same manner as user B calculates, it. That is, the adversary can calculate K as, K = (YA)XB mod q, The security of the Diffie–Hellman key exchange lies in the fact that, while, it is relatively easy to calculate exponentials modulo a prime, it is very difficult, to calculate discrete logarithms. For large primes, the latter task is considered, infeasible., Here is an example. Key exchange is based on the use of the prime number, q = 353 and a primitive root of 353, in this case a = 3. A and B select private keys, XA = 97 and XB = 233, respectively. Each computes its public key:, A computes YA = 397 mod 353 = 40., B computes YB = 3233 mod 353 = 248., After they exchange public keys, each can compute the common secret key:, A computes K = (YB)XA mod 353 = 24897 mod 353 = 160., B computes K = (YA)XB mod 353 = 40233 mod 353 = 160., We assume an attacker would have available the following information:, q = 353; a = 3; YA = 40; YB = 248, In this simple example, it would be possible by brute force to determine the secret, key 160. In particular, an attacker E can determine the common key by discovering, a solution to the equation 3a mod 353 = 40 or the equation 3b mod 353 = 248. The, brute-force approach is to calculate powers of 3 modulo 353, stopping when the result equals either 40 or 248. The desired answer is reached with the exponent value, of 97, which provides 397 mod 353 = 40., With larger numbers, the problem becomes impractical., , Hiva-Network.Com
Page 318 :
10.1 / DIFFIE–HELLMAN KEY EXCHANGE, , 317, , Key Exchange Protocols, Figure 10.1 shows a simple protocol that makes use of the Diffie–Hellman calculation. Suppose that user A wishes to set up a connection with user B and use a secret, key to encrypt messages on that connection. User A can generate a one-time private key XA, calculate YA, and send that to user B. User B responds by generating, a private value XB, calculating YB, and sending YB to user A. Both users can now, calculate the key. The necessary public values q and a would need to be known, ahead of time. Alternatively, user A could pick values for q and a and include those, in the first message., As an example of another use of the Diffie–Hellman algorithm, suppose that a, group of users (e.g., all users on a LAN) each generate a long-lasting private value Xi, (for user i) and calculate a public value Yi. These public values, together with global, public values for q and a, are stored in some central directory. At any time, user j, can access user i’s public value, calculate a secret key, and use that to send an encrypted message to user A. If the central directory is trusted, then this form of communication provides both confidentiality and a degree of authentication. Because, only i and j can determine the key, no other user can read the message (confidentiality). Recipient i knows that only user j could have created a message using this key, (authentication). However, the technique does not protect against replay attacks., , Man-in-the-Middle Attack, The protocol depicted in Figure 10.1 is insecure against a man-in-the-middle attack., Suppose Alice and Bob wish to exchange keys, and Darth is the adversary. The attack proceeds as follows (Figure 10.2)., 1. Darth prepares for the attack by generating two random private keys XD1 and, XD2 and then computing the corresponding public keys YD1 and YD2., 2. Alice transmits YA to Bob., 3. Darth intercepts YA and transmits YD1 to Bob. Darth also calculates, K2 = (YA)XD2 mod q., 4. Bob receives YD1 and calculates K1 = (YD1)XB mod q., 5. Bob transmits YB to Alice., 6. Darth intercepts YB and transmits YD2 to Alice. Darth calculates, K1 = (YB)XD1 mod q., 7. Alice receives YD2 and calculates K2 = (YD2)XA mod q., At this point, Bob and Alice think that they share a secret key, but instead, Bob and Darth share secret key K1 and Alice and Darth share secret key K2. All, future communication between Bob and Alice is compromised in the following way., 1. Alice sends an encrypted message M: E(K2, M)., 2. Darth intercepts the encrypted message and decrypts it to recover M., 3. Darth sends Bob E(K1, M) or E(K1, M=), where M= is any message. In the first, case, Darth simply wants to eavesdrop on the communication without altering, it. In the second case, Darth wants to modify the message going to Bob.
Page 319 :
318, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , Alice, , Darth, , Bob, , Private key XA, Public key, YA = AXA mod q, YA, , YD2, Secret key, K2 = (YD2)XA mod q, , Private keys XD1, XD2, Public keys, YD1 = AXD1 mod q, YD2 = AXD2 mod q, , YD1, Private key XB, Public key, YB = AXB mod q, , Secret key, K2 = (YA)XD2 mod q, , YB, Secret key, K1 = (YB)XD1 mod q, Alice and Darth, share K2, , Figure 10.2, , Secret key, K1 = (YD1)XB mod q, Bob and Darth, share K1, , Man-in-the-Middle Attack, , The key exchange protocol is vulnerable to such an attack because it does not, authenticate the participants. This vulnerability can be overcome with the use of digital, signatures and public-key certificates; these topics are explored in Chapters 13 and 14., , 10.2 ELGAMAL CRYPTOGRAPHIC SYSTEM, In 1984, T. Elgamal announced a public-key scheme based on discrete logarithms,, closely related to the Diffie–Hellman technique [ELGA84, ELGA85]. The Elgamal2, cryptosystem is used in some form in a number of standards including the digital, signature standard (DSS), which is covered in Chapter 13, and the S/MIME email, standard (Chapter 19)., 2, For no apparent reason, most of the literature uses the term ElGamal, although Mr. Elgamal’s last name, does not have a capital letter G.
Page 320 :
10.2 / ELGAMAL CRYPTOGRAPHIC SYSTEM, , 319, , As with Diffie–Hellman, the global elements of Elgamal are a prime number q and, a, which is a primitive root of q. User A generates a private/public key pair as follows:, 1. Generate a random integer XA, such that 1 6 XA 6 q - 1., 2. Compute YA = aXA mod q., 3. A’s private key is XA and A’s public key is {q, a, YA}., Any user B that has access to A’s public key can encrypt a message as follows:, 1. Represent the message as an integer M in the range 0 … M … q - 1. Longer, messages are sent as a sequence of blocks, with each block being an integer, less than q., 2. Choose a random integer k such that 1 … k … q - 1., 3. Compute a one-time key K = (YA)k mod q., 4. Encrypt M as the pair of integers (C1, C2) where, C1 = ak mod q; C2 = KM mod q, User A recovers the plaintext as follows:, 1. Recover the key by computing K = (C1)XA mod q., 2. Compute M = (C2K -1) mod q., These steps are summarized in Figure 10.3. It corresponds to Figure 9.1a:, Alice generates a public/private key pair; Bob encrypts using Alice’s public key; and, Alice decrypts using her private key., Let us demonstrate why the Elgamal scheme works. First, we show how K is, recovered by the decryption process:, K, K, K, K, , =, =, =, =, , (YA)k mod q, (aXA mod q)k mod q, akXA mod q, (C1)XA mod q, , K is defined during the encryption process, substitute using YA = aXA mod q, by the rules of modular arithmetic, substitute using C1 = ak mod q, , Next, using K, we recover the plaintext as, C2 = KM mod q, (C2K -1) mod q = KMK -1 mod q = M mod q = M, We can restate the Elgamal process as follows, using Figure 10.3., 1. Bob generates a random integer k., 2. Bob generates a one-time key K using Alice’s public-key components YA, q,, and k., 3. Bob encrypts k using the public-key component a, yielding C1. C1 provides, sufficient information for Alice to recover K., 4. Bob encrypts the plaintext message M using K., 5. Alice recovers K from C1 using her private key., 6. Alice uses K -1 to recover the plaintext message from C2.
Page 321 :
320, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, Global Public Elements, q, , prime number, , a, , a 6 q and a a primitive root of q, , Key Generation by Alice, Select private XA, , XA 6 q - 1, , Calculate YA, , YA = aXA mod q, , Public key, , {q, a, YA}, , Private key, , XA, , Encryption by Bob with Alice’s Public Key, Plaintext:, , M 6 q, , Select random integer k, , k 6 q, , Calculate K, , K = (YA)k mod q, , Calculate C1, , C1 = ak mod q, , Calculate C2, , C2 = KM mod q, , Ciphertext:, , (C1, C2), , Decryption by Alice with Alice’s Private Key, Ciphertext:, , (C1, C2), , Calculate K, , K = (C1)XA mod q, , Plaintext:, , M = (C2K -1) mod q, , Figure 10.3 The Elgamal Cryptosystem, , Thus, K functions as a one-time key, used to encrypt and decrypt the message., For example, let us start with the prime field GF(19); that is, q = 19. It has, primitive roots {2, 3, 10, 13, 14, 15}, as shown in Table 2.7. We choose a = 10., Alice generates a key pair as follows:, 1. Alice chooses XA = 5., 2. Then YA = aXA mod q = a5 mod 19 = 3 (see Table 2.7)., 3. Alice’s private key is 5 and Alice’s public key is {q, a, YA} = {19, 10, 3}., Suppose Bob wants to send the message with the value M = 17. Then:
Page 322 :
10.3 / ELLIPTIC CURVE ARITHMETIC, , 321, , 1. Bob chooses k = 6., 2. Then K = (YA)k mod q = 36 mod 19 = 729 mod 19 = 7., 3. So, C1 = ak mod q = a6 mod 19 = 11, C2 = KM mod q = 7 * 17 mod 19 = 119 mod 19 = 5, 4. Bob sends the ciphertext (11, 5)., For decryption:, 1. Alice calculates K = (C1)XA mod q = 115 mod 19 = 161051 mod 19 = 7., 2. Then K -1 in GF(19) is 7-1 mod 19 = 11., 3. Finally, M = (C2K -1) mod q = 5 * 11 mod 19 = 55 mod 19 = 17., If a message must be broken up into blocks and sent as a sequence of encrypted, blocks, a unique value of k should be used for each block. If k is used for more than, one block, knowledge of one block M1 of the message enables the user to compute, other blocks as follows. Let, C1,1 = ak mod q; C2,1 = KM1 mod q, C1,2 = ak mod q; C2,2 = KM2 mod q, Then,, C2,1, C2,2, , =, , KM1 mod q, M1 mod q, =, KM2 mod q, M2 mod q, , If M1 is known, then M2 is easily computed as, M2 = (C2,1)-1 C2,2 M1 mod q, The security of Elgamal is based on the difficulty of computing discrete, logarithms. To recover A’s private key, an adversary would have to compute, XA = dlog a,q(YA). Alternatively, to recover the one-time key K, an adversary, would have to determine the random number k, and this would require computing, the discrete logarithm k = dlog a,q(C1). [STIN06] points out that these calculations, are regarded as infeasible if p is at least 300 decimal digits and q - 1 has at least one, “large” prime factor., , 10.3 ELLIPTIC CURVE ARITHMETIC, Most of the products and standards that use public-key cryptography for encryption and digital signatures use RSA. As we have seen, the key length for secure, RSA use has increased over recent years, and this has put a heavier processing, load on applications using RSA. This burden has ramifications, especially for electronic commerce sites that conduct large numbers of secure transactions. A competing system challenges RSA: elliptic curve cryptography (ECC). ECC is showing, up in standardization efforts, including the IEEE P1363 Standard for Public-Key, Cryptography.
Page 323 :
322, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , The principal attraction of ECC, compared to RSA, is that it appears to offer, equal security for a far smaller key size, thereby reducing processing overhead., ECC is fundamentally more difficult to explain than either RSA or Diffie–, Hellman, and a full mathematical description is beyond the scope of this book. This, section and the next give some background on elliptic curves and ECC. We begin, with a brief review of the concept of abelian group. Next, we examine the concept, of elliptic curves defined over the real numbers. This is followed by a look at elliptic curves defined over finite fields. Finally, we are able to examine elliptic curve, ciphers., The reader may wish to review the material on finite fields in Chapter 5 before, proceeding., , Abelian Groups, Recall from Chapter 5 that an abelian group G, sometimes denoted by {G, # }, is a, set of elements with a binary operation, denoted by # , that associates to each ordered pair (a, b) of elements in G an element (a # b) in G, such that the following, axioms are obeyed:3, (A1) Closure:, , If a and b belong to G, then a # b is also in G., , (A2) Associative:, , a # (b # c) = (a # b) # c for all a, b, c in G., , (A3) Identity element:, , There is an element e in G such that a # e = e # a = a, for all a in G., , (A4) Inverse element:, , For each a in G there is an element a′ in G such that, a # a′ = a′ # a = e., , (A5) Commutative:, , a # b = b # a for all a, b in G., , v, , A number of public-key ciphers are based on the use of an abelian group., For example, Diffie–Hellman key exchange involves multiplying pairs of nonzero, integers modulo a prime number q. Keys are generated by exponentiation over, the group, with exponentiation defined as repeated multiplication. For example,, ak mod q = (a * a * c * a) mod q. To attack Diffie–Hellman, the attacker must, k times, determine k given a and ak; this is the discrete logarithm problem., For elliptic curve cryptography, an operation over elliptic curves, called addition, is used. Multiplication is defined by repeated addition. For example,, v, , a * k = (a + a + c + a), k times, where the addition is performed over an elliptic curve. Cryptanalysis involves determining k given a and (a * k)., , 3, The operator # is generic and can refer to addition, multiplication, or some other mathematical, operation.
Page 324 :
10.3 / ELLIPTIC CURVE ARITHMETIC, , 323, , An elliptic curve is defined by an equation in two variables with coefficients., For cryptography, the variables and coefficients are restricted to elements in a finite, field, which results in the definition of a finite abelian group. Before looking at this,, we first look at elliptic curves in which the variables and coefficients are real numbers. This case is perhaps easier to visualize., , Elliptic Curves over Real Numbers, Elliptic curves are not ellipses. They are so named because they are described by, cubic equations, similar to those used for calculating the circumference of an ellipse., In general, cubic equations for elliptic curves take the following form, known as a, Weierstrass equation:, y2 + axy + by = x3 + cx2 + dx + e, where a, b, c, d, e are real numbers and x and y take on values in the real numbers.4, For our purpose, it is sufficient to limit ourselves to equations of the form, y2 = x3 + ax + b, , (10.1), , Such equations are said to be cubic, or of degree 3, because the highest exponent they contain is a 3. Also included in the definition of an elliptic curve is a, single element denoted O and called the point at infinity or the zero point, which we, discuss subsequently. To plot such a curve, we need to compute, y = 2x3 + ax + b, For given values of a and b, the plot consists of positive and negative values of y for, each value of x. Thus, each curve is symmetric about y = 0. Figure 10.4 shows two, examples of elliptic curves. As you can see, the formula sometimes produces weirdlooking curves., Now, consider the set of points E(a, b) consisting of all of the points (x, y) that, satisfy Equation (10.1) together with the element O. Using a different value of the, pair (a, b) results in a different set E(a, b). Using this terminology, the two curves in, Figure 10.4 depict the sets E(-1, 0) and E(1, 1), respectively., GEOMETRIC DESCRIPTION OF ADDITION It can be shown that a group can be defined, based on the set E(a, b) for specific values of a and b in Equation (10.1), provided, the following condition is met:, 4a3 + 27b2 ≠ 0, , (10.2), , To define the group, we must define an operation, called addition and denoted by, +, for the set E(a, b), where a and b satisfy Equation (10.2). In geometric terms, the, rules for addition can be stated as follows: If three points on an elliptic curve lie on a, straight line, their sum is O. From this definition, we can define the rules of addition, over an elliptic curve., , 4, , Note that x and y are true variables, which take on values. This is in contrast to our discussion of polynomial rings and fields in Chapter 5, where was treated as an indeterminate.
Page 325 :
324, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , 4, -(P + Q), 2, Q, 0, P, -2, (P + Q), -4, -2, , 0, , -1, , 1, , 2, 2, , 3, , 4, , 5, , 3, , 4, , 5, , 3, , (a) y = x - x, , -(P + Q), , 4, , 2, Q, 0, , P, , -2, , (P + Q), , -4, -2, , -1, , 0, , 1, , 2, , (b) y2 = x3 + x + 1, , Figure 10.4, , Example of Elliptic Curves, , 1. O serves as the additive identity. Thus O = -O; for any point P on the elliptic, curve, P + O = P. In what follows, we assume P ≠ O and Q ≠ O., 2. The negative of a point P is the point with the same x coordinate but the negative of the y coordinate; that is, if P = (x, y), then -P = (x, -y). Note that these, two points can be joined by a vertical line. Note that P + ( -P) = P - P = O., 3. To add two points P and Q with different x coordinates, draw a straight line, between them and find the third point of intersection R. It is easily seen that, there is a unique point R that is the point of intersection (unless the line is, tangent to the curve at either P or Q, in which case we take R = P or R = Q,, respectively). To form a group structure, we need to define addition on these, three points: P + Q = -R. That is, we define P + Q to be the mirror image
Page 326 :
10.3 / ELLIPTIC CURVE ARITHMETIC, , 325, , (with respect to the x axis) of the third point of intersection. Figure 10.4 illustrates this construction., 4. The geometric interpretation of the preceding item also applies to two points,, P and -P, with the same x coordinate. The points are joined by a vertical line,, which can be viewed as also intersecting the curve at the infinity point. We, therefore have P + ( -P) = O, which is consistent with item (2)., 5. To double a point Q, draw the tangent line and find the other point of intersection S. Then Q + Q = 2Q = -S., With the preceding list of rules, it can be shown that the set E(a, b) is an abelian group., ALGEBRAIC DESCRIPTION OF ADDITION In this subsection, we present some results, that enable calculation of additions over elliptic curves.5 For two distinct points,, P = (xP, yP) and Q = (xQ, yQ), that are not negatives of each other, the slope of the, line l that joins them is ∆ = (yQ - yP)/(xQ - xP). There is exactly one other point, where l intersects the elliptic curve, and that is the negative of the sum of P and Q., After some algebraic manipulation, we can express the sum R = P + Q as, xR = ∆2 - xP - xQ, yR = -yP + ∆(xP - xR), , (10.3), , We also need to be able to add a point to itself: P + P = 2P = R. When, yP ≠ 0, the expressions are, xR = ¢, , 3x2P + a 2, ≤ - 2xP, 2yP, , (10.4), , 3x2P + a, yR = ¢, ≤(xP - xR) - yP, 2yP, , Elliptic Curves over Z p, Elliptic curve cryptography makes use of elliptic curves in which the variables and, coefficients are all restricted to elements of a finite field. Two families of elliptic, curves are used in cryptographic applications: prime curves over Zp and binary, curves over GF(2m). For a prime curve over Z p, we use a cubic equation in which, the variables and coefficients all take on values in the set of integers from 0 through, p - 1 and in which calculations are performed modulo p. For a binary curve defined over GF(2m), the variables and coefficients all take on values in GF(2m) and, in calculations are performed over GF(2m). [FERN99] points out that prime curves, are best for software applications, because the extended bit-fiddling operations, needed by binary curves are not required; and that binary curves are best for hardware applications, where it takes remarkably few logic gates to create a powerful,, fast cryptosystem. We examine these two families in this section and the next., , 5, , For derivations of these results, see [KOBL94] or other mathematical treatments of elliptic curves., , Hiva-Network.Com
Page 327 :
326, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , There is no obvious geometric interpretation of elliptic curve arithmetic over, finite fields. The algebraic interpretation used for elliptic curve arithmetic over real, numbers does readily carry over, and this is the approach we take., For elliptic curves over Z p, as with real numbers, we limit ourselves to equations of the form of Equation (10.1), but in this case with coefficients and variables, limited to Z p:, y2 mod p = (x3 + ax + b) mod p, , (10.5), , For example, Equation (10.5) is satisfied for a = 1, b = 1, x = 9, y = 7, p = 23:, 72 mod 23 = (93 + 9 + 1) mod 23, 49 mod 23 = 739 mod 23, 3 = 3, Now consider the set E p(a, b) consisting of all pairs of integers (x, y) that satisfy Equation (10.5), together with a point at infinity O. The coefficients a and b and, the variables x and y are all elements of Z p., For example, let p = 23 and consider the elliptic curve y2 = x3 + x + 1. In, this case, a = b = 1. Note that this equation is the same as that of Figure 10.4b. The, figure shows a continuous curve with all of the real points that satisfy the equation., For the set E 23(1, 1), we are only interested in the nonnegative integers in the quadrant from (0, 0) through (p - 1, p - 1) that satisfy the equation mod p. Table 10.1, lists the points (other than O) that are part of E 23(1, 1). Figure 10.5 plots the points, of E 23(1, 1); note that the points, with one exception, are symmetric about y = 11.5., It can be shown that a finite abelian group can be defined based on the set, E p(a, b) provided that (x3 + ax + b) mod p has no repeated factors. This is equivalent to the condition, (4a3 + 27b2) mod p ≠ 0 mod p, , (10.6), , Note that Equation (10.6) has the same form as Equation (10.2)., The rules for addition over E p(a, b), correspond to the algebraic technique described for elliptic curves defined over real numbers. For all points P, Q ∈ E p(a, b):, Table 10.1, , Points (other than O) on the, Elliptic Curve E 23(1, 1), , (0, 1), , (6, 4), , (12, 19), , (0, 22), , (6, 19), , (13, 7), , (1, 7), , (7, 11), , (13, 16), , (1, 16), , (7, 12), , (17, 3), , (3, 10), , (9, 7), , (17, 20), , (3, 13), , (9, 16), , (18, 3), , (4, 0), , (11, 3), , (18, 20), , (5, 4), , (11, 20), , (19, 5), , (5, 19), , (12, 4), , (19, 18)
Page 328 :
10.3 / ELLIPTIC CURVE ARITHMETIC, , 327, , 22, 21, 20, 19, 18, 17, 16, 15, , y, , 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, 0, , 1, , 2, , 3, , 4, , 5, , 6, , 7, , 8, , 9 10 11 12 13 14 15 16 17 18 19 20 21 22, x, , Figure 10.5 The Elliptic Curve E 23(1, 1), , 1. P + O = P., 2. If P = (xP, yP), then P + (xP, -yP) = O. The point (xP, -yP) is the negative of P, denoted as -P. For example, in E 23(1, 1), for P = (13, 7), we have, -P = (13, -7). But -7 mod 23 = 16. Therefore, -P = (13, 16), which is also, in E23(1, 1)., 3. If P = (xp, yp) and Q = (xQ, yQ) with P ≠ -Q, then R = P + Q = (xR, yR), is determined by the following rules:, xR = (l2 - xP - xQ) mod p, yR = (l(xP - xR) - yP) mod p, where, a, l = e, a, , yQ - yP, xQ - xP, 3x2P + a, 2yP, , b mod p, , if P ≠ Q, , b mod p, , if P = Q
Page 329 :
328, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , 4. Multiplication is defined as repeated addition; for example, 4P =, P + P + P + P., For example, let P = (3, 10) and Q = (9, 7) in E23(1, 1). Then, l = a, , 7 - 10, -3, -1, b mod 23 = a, b mod 23 = a, b mod 23 = 11, 9 - 3, 6, 2, , xR = (112 - 3 - 9) mod 23 = 109 mod 23 = 17, yR = (11(3 - 17) - 10) mod 23 = -164 mod 23 = 20, So P + Q = (17, 20). To find 2P,, 3(32) + 1, 5, 1, ≤ mod 23 = a b mod 23 = a b mod 23 = 6, 2 * 10, 20, 4, The last step in the preceding equation involves taking the multiplicative inverse of 4 in Z 23. This can be done using the extended Euclidean algorithm defined, in Section 4.4. To confirm, note that (6 * 4) mod 23 = 24 mod 23 = 1., l = ¢, , xR = (62 - 3 - 3) mod 23 = 30 mod 23 = 7, yR = (6(3 - 7) - 10) mod 23 = ( -34) mod 23 = 12, and 2P = (7, 12)., For determining the security of various elliptic curve ciphers, it is of some interest to know the number of points in a finite abelian group defined over an elliptic, curve. In the case of the finite group EP(a, b), the number of points N is bounded by, p + 1 - 22p … N … p + 1 + 22p, Note that the number of points in Ep(a, b) is approximately equal to the number of, elements in Zp, namely p elements., , Elliptic Curves over GF(2m), Recall from Chapter 5 that a finite field GF(2m) consists of 2m elements, together, with addition and multiplication operations that can be defined over polynomials., For elliptic curves over GF(2m), we use a cubic equation in which the variables and, coefficients all take on values in GF(2m) for some number m and in which calculations are performed using the rules of arithmetic in GF(2m)., , Table 10.2, (0, 1), 6, , (1, g ), , 5, , (g 10, g), , 8, , (g , g ), (g , g ), , (g 10, g 8), , (g6, g14), , (g 12, 0), , 13, , (g , g ), , 6, , (g 9, g 13), , 11, , 8, , (g , g ), 3, , (g5, g3), , 13, , (1, g ), 3, , Points (other than O) on the, Elliptic Curve E 24(g4, 1), , 9, , 10, , (g , g ), , (g 12, g 12)
Page 332 :
10.4 / ELLIPTIC CURVE CRYPTOGRAPHY, , 331, , Because 9P = (4, 5) = Q, the discrete logarithm Q = (4, 5) to the base, P = (16, 5) is k = 9. In a real application, k would be so large as to make the bruteforce approach infeasible., In the remainder of this section, we show two approaches to ECC that give the, flavor of this technique., , Analog of Diffie–Hellman Key Exchange, Key exchange using elliptic curves can be done in the following manner. First pick, a large integer q, which is either a prime number p or an integer of the form 2m,, and elliptic curve parameters a and b for Equation (10.5) or Equation (10.7). This, defines the elliptic group of points Eq(a, b). Next, pick a base point G = (x1, y1) in, Ep(a, b) whose order is a very large value n. The order n of a point G on an elliptic, curve is the smallest positive integer n such that nG = 0 and G are parameters of, the cryptosystem known to all participants., A key exchange between users A and B can be accomplished as follows, (Figure 10.7)., 1. A selects an integer nA less than n. This is A’s private key. A then generates a, public key PA = nA * G; the public key is a point in Eq(a, b)., 2. B similarly selects a private key nB and computes a public key PB., 3. A generates the secret key k = nA * PB. B generates the secret key, k = nB * PA., The two calculations in step 3 produce the same result because, nA * PB = nA * (nB * G) = nB * (nA * G) = nB * PA, To break this scheme, an attacker would need to be able to compute k given G, and kG, which is assumed to be hard., As an example,6 take p = 211; E p(0, -4), which is equivalent to the curve, 2, y = x3 - 4; and G = (2, 2). One can calculate that 240G = O. A’s private key, is nA = 121, so A’s public key is PA = 121(2, 2) = (115, 48). B’s private key is, nB = 203, so B’s public key is 203(2, 3) = (130, 203). The shared secret key is, 121(130, 203) = 203(115, 48) = (161, 69)., Note that the secret key is a pair of numbers. If this key is to be used as a session key for conventional encryption, then a single number must be generated. We, could simply use the x coordinates or some simple function of the x coordinate., , Elliptic Curve Encryption/Decryption, Several approaches to encryption/decryption using elliptic curves have been analyzed in the literature. In this subsection, we look at perhaps the simplest. The, first task in this system is to encode the plaintext message m to be sent as an (x, y), point Pm., , 6, , Provided by Ed Schaefer of Santa Clara University.
Page 333 :
332, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, Global Public Elements, E q(a, b), , elliptic curve with parameters a, b, and q, where q is a, prime or an integer of the form 2m, , G, , point on elliptic curve whose order is large value n, , User A Key Generation, Select private nA, , nA 6 n, , Calculate public PA, , PA = nA * G, , User B Key Generation, Select private nB, , nB 6 n, , Calculate public PB, , PB = nB * G, , Calculation of Secret Key by User A, K = nA * PB, , Calculation of Secret Key by User B, K = nB * PA, Figure 10.7, , ECC Diffie–Hellman Key Exchange, , It is the point Pm that will be encrypted as a ciphertext and subsequently decrypted., Note that we cannot simply encode the message as the x or y coordinate of a point,, because not all such coordinates are in Eq(a, b); for example, see Table 10.1. Again,, there are several approaches to this encoding, which we will not address here, but, suffice it to say that there are relatively straightforward techniques that can be, used., As with the key exchange system, an encryption/decryption system requires a, point G and an elliptic group Eq(a, b) as parameters. Each user A selects a private, key nA and generates a public key PA = nA * G., To encrypt and send a message Pm to B, A chooses a random positive integer, k and produces the ciphertext Cm consisting of the pair of points:, Cm = {kG, Pm + kPB}, Note that A has used B’s public key PB. To decrypt the ciphertext, B multiplies the, first point in the pair by B’s private key and subtracts the result from the second, point:, Pm + kPB - nB(kG) = Pm + k(nBG) - nB(kG) = Pm
Page 334 :
10.4 / ELLIPTIC CURVE CRYPTOGRAPHY, , 333, , Table 10.3 Comparable Key Sizes in Terms of Computational, Effort for Cryptanalysis (NIST SP-800-57), Symmetric Key, Algorithms, 80, 112, 128, 192, 256, , Diffie–Hellman, Digital, Signature Algorithm, L, N, L, N, L, N, L, N, L, N, , =, =, =, =, =, =, =, =, =, =, , 1024, 160, 2048, 224, 3072, 256, 7680, 384, 15,360, 512, , RSA, (size of n in bits), , ECC, (modulus size in bits), , 1024, , 160–223, , 2048, , 224–255, , 3072, , 256–383, , 7680, , 384–511, , 15,360, , 512 +, , Note: L = size of public key, N = size of private key., , A has masked the message Pm by adding kPB to it. Nobody but A knows, the value of k, so even though Pb is a public key, nobody can remove the mask, kPB. However, A also includes a “clue,” which is enough to remove the mask if, one knows the private key nB. For an attacker to recover the message, the attacker, would have to compute k given G and kG, which is assumed to be hard., Let us consider a simple example. The global public elements are q = 257;, E q(a, b) = E 257(0, -4), which is equivalent to the curve y2 = x3 - 4; and G =, (2, 2). Bob’s private key is nB = 101, and his public key is PB = nBG = 101(2, 2) =, (197, 167). Alice wishes to send a message to Bob that is encoded in the elliptic, point Pm = (112, 26). Alice chooses random integer k = 41 and computes kG =, 41(2, 2) = (136, 128), kPB = 41(197, 167) = (68, 84) and Pm + kPB = (112, 26), + (68, 84) = (246, 174). Alice sends the ciphertext Cm = (C1, C2) = {(136, 128),, (246, 174)} to Bob. Bob receives the ciphertext and computes C2 - nBC1 =, (246, 174) - 101(136, 128) = (246, 174) - (68, 84) = (112, 26)., , Security of Elliptic Curve Cryptography, The security of ECC depends on how difficult it is to determine k given kP and P., This is referred to as the elliptic curve logarithm problem. The fastest known technique for taking the elliptic curve logarithm is known as the Pollard rho method., Table 10.3, from NIST SP 800-57 (Recommendation for Key Management—Part 1:, General, September 2015), compares various algorithms by showing comparable, key sizes in terms of computational effort for cryptanalysis. As can be seen, a considerably smaller key size can be used for ECC compared to RSA., Based on this analysis, SP 800-57 recommends that at least through 2030, acceptable key lengths are from 3072 to 14,360 bits for RSA and 256 to 512 bits for, ECC. Similarly, the European Union Agency for Network and Information Security, (ENISA) recommends in their 2014 report (Algorithms, Key Size and Parameters, report—2014, November 2014) minimum key lengths for future system of 3072 bits, and 256 bits for RSA and ECC, respectively.
Page 335 :
334, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , Analysis indicates that for equal key lengths, the computational effort required for ECC and RSA is comparable [JURI97]. Thus, there is a computational, advantage to using ECC with a shorter key length than a comparably secure RSA., , 10.5 PSEUDORANDOM NUMBER GENERATION BASED, ON AN ASYMMETRIC CIPHER, We noted in Chapter 8 that because a symmetric block cipher produces an apparently random output, it can serve as the basis of a pseudorandom number generator, (PRNG). Similarly, an asymmetric encryption algorithm produces apparently random output and can be used to build a PRNG. Because asymmetric algorithms are, typically much slower than symmetric algorithms, asymmetric algorithms are not, used to generate open-ended PRNG bit streams. Rather, the asymmetric approach, is useful for creating a pseudorandom function (PRF) for generating a short pseudorandom bit sequence., In this section, we examine two PRNG designs based on pseudorandom, functions., , PRNG Based on RSA, For a sufficient key length, the RSA algorithm is considered secure and is a good, candidate to form the basis of a PRNG. Such a PRNG, known as the Micali–Schnorr, PRNG [MICA91], is recommended in the ANSI standard X9.82 (Random Number, Generation) and in the ISO standard 18031 (Random Bit Generation)., The PRNG is illustrated in Figure 10.8. As can be seen, this PRNG has much, the same structure as the output feedback (OFB) mode used as a PRNG (see Figure, 8.4b and the portion of Figure 7.6a enclosed with a dashed box). In this case, the, encryption algorithm is RSA rather than a symmetric block cipher. Also, a portion, of the output is fed back to the next iteration of the encryption algorithm and the, remainder of the output is used as pseudorandom bits. The motivation for this separation of the output into two distinct parts is so that the pseudorandom bits from, one stage do not provide input to the next stage. This separation should contribute, to forward unpredictability., Seed = x0, n, e, r, k, , n, e, r, k, Encrypt, , Encrypt, , Encrypt, , y1 = xe0 mod n, , y2 = xe1 mod n, , y3 = xe2 mod n, , x1 = r most, significant bits, z1 = k least, significant bits, , Figure 10.8, , Hiva-Network.Com, , n, e, r, k, , x2 = r most, significant bits, z2 = k least, significant bits, , x3 = r most, significant bits, z3 = k least, significant bits, , Micali–Schnorr Pseudorandom Bit Generator
Page 336 :
10.5 / PSEUDORANDOM NUMBER GENERATION BASED ON AN ASYMMETRIC CIPHER, , 335, , We can define the PRNG as follows., Setup, , Select p, q primes; n = pq; f(n) = (p - 1)(q - 1). Select e such, that gcd(e, f(n)) = 1. These are the standard RSA setup selections, (see Figure 9.5). In addition, let N = [log 2n] + 1 (the bitlength of n)., Select r, k such that r + k = N., , Seed, , Select a random seed x0 of bitlength r., , Generate, , Generate a pseudorandom sequence of length k * m using the loop, for i from 1 to m do, yi = xei - 1 mod n, xi = r most significant bits of yi, zi = k least significant bits of yi, , Output, , The output sequence is z1 } z2 } c } zm., , The parameters n, r, e, and k are selected to satisfy the following six, requirements., 1. n = pq, , n is chosen as the product of two primes to, have the cryptographic strength required of, RSA., , 2. 1 6 e 6 f(n); gcd (e, f(n)) = 1, , Ensures that the mapping s S se mod n is, 1 to 1., , 3. re Ú 2N, , Ensures that the exponentiation requires a, full modular reduction., , 4. r Ú 2 * strength, , Protects against a cryptographic attacks., , 5. k, r are multiples of 8, , An implementation convenience., , 6. k Ú 8; r + k = N, , All bits are used., , The variable strength in requirement 4 is defined in NIST SP 800-90 as follows: A number associated with the amount of work (that is, the number of operations) required to break a cryptographic algorithm or system; a security strength, is specified in bits and is a specific value from the set (112, 128, 192, 256) for this, Recommendation. The amount of work needed is 2strength., There is clearly a tradeoff between r and k. Because RSA is computationally intensive compared to a block cipher, we would like to generate as many, pseudorandom bits per iteration as possible and therefore would like a large, value of k. However, for cryptographic strength, we would like r to be as large as, possible., For example, if e = 3 and N = 1024, then we have the inequality 3r 7 1024,, yielding a minimum required size for r of 683 bits. For r set to that size, k = 341, bits are generated for each exponentiation (each RSA encryption). In this case,, each exponentiation requires only one modular squaring of a 683-bit number and, one modular multiplication. That is, we need only calculate (xi * (x2i mod n)), mod n.
Page 337 :
336, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , PRNG Based on Elliptic Curve Cryptography, In this subsection, we briefly summarize a technique developed by the U.S. National, Security Agency (NSA) known as dual elliptic curve PRNG (DEC PRNG). This, technique is recommended in NIST SP 800-90, the ANSI standard X9.82, and the, ISO standard 18031. There has been some controversy regarding both the security, and efficiency of this algorithm compared to other alternatives (e.g., see [SCHO06],, [BROW07])., [SCHO06] summarizes the algorithm as follows: Let P and Q be two known, points on a given elliptic curve. The seed of the DEC PRNG is a random integer, s0 ∈ {0, 1, c , #E(GF(p)) - 1}, where # E(GF(p)) denotes the number of points, on the curve. Let x denote a function that gives the x-coordinate of a point of the, curve. Let lsbi(s) denote the i least significant bits of an integer s. The DEC PRNG, transforms the seed into the pseudorandom sequence of length 240k, k 7 0, as, follows., for i = 1, Set si, Set ri, end for, Return, , to k do, d x(Si-1 P), d lsb240 (x(si Q)), r1,...,rk, , Given the security concerns expressed for this PRNG, the only motivation for, its use would be that it is used in a system that already implements ECC but does, not implement any other symmetric, asymmetric, or hash cryptographic algorithm, that could be used to build a PRNG., , 10.6 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, abelian group, binary curve, cubic equation, Diffie–Hellman key exchange, discrete logarithm, , elliptic curve, elliptic curve arithmetic, elliptic curve cryptography, finite field, man-in-the-middle attack, , Micali–Schnorr, prime curve, primitive root, zero point, , Review Questions, 10.1, 10.2, 10.3, 10.4, , Briefly explain Diffie–Hellman key exchange., What is an elliptic curve?, What is the zero point of an elliptic curve?, What is the sum of three points on an elliptic curve that lie on a straight line?
Page 338 :
10.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 337, , Problems, 10.1, , 10.2, , 10.3, , 10.4, , 10.5, , 10.6, , 10.7, , 10.8, 10.9, 10.10, 10.11, , Alice and Bob use the Diffie–Hellman key exchange technique with a common prime, q = 1 5 7 and a primitive root a = 5., a. If Alice has a private key XA = 15, find her public key YA., b. If Bob has a private key XB = 27, find his public key YB., c. What is the shared secret key between Alice and Bob?, Alice and Bob use the Diffie-Hellman key exchange technique with a common prime, q = 2 3 and a primitive root a = 5 ., a. If Bob has a public key YB = 1 0 , what is Bob’s private key YB?, b. If Alice has a public key YA = 8 , what is the shared key K with Bob?, c. Show that 5 is a primitive root of 23., In the Diffie–Hellman protocol, each participant selects a secret number x and sends, the other participant ax mod q for some public number a. What would happen if the, participants sent each other xa for some public number a instead? Give at least one, method Alice and Bob could use to agree on a key. Can Eve break your system without finding the secret numbers? Can Eve find the secret numbers?, This problem illustrates the point that the Diffie–Hellman protocol is not secure, without the step where you take the modulus; i.e. the “Indiscrete Log Problem” is, not a hard problem! You are Eve and have captured Alice and Bob and imprisoned, them. You overhear the following dialog., Bob:, , Oh, let’s not bother with the prime in the Diffie–Hellman protocol, it will, make things easier., , Alice:, , Okay, but we still need a base a to raise things to. How about a = 3?, , Bob:, , All right, then my result is 27., , Alice:, , And mine is 243., , What is Bob’s private key XB and Alice’s private key XA? What is their secret combined key? (Don’t forget to show your work.), Section 10.1 describes a man-in-the-middle attack on the Diffie–Hellman key, exchange protocol in which the adversary generates two public–private key pairs for, the attack. Could the same attack be accomplished with one pair? Explain., Suppose Alice and Bob use an Elgamal scheme with a common prime q = 1 5 7 and, a primitive root a = 5 ., a. If Bob has public key YB = 1 0 and Alice chose the random integer k = 3 , what, is the ciphertext of M = 9 ?, b. If Alice now chooses a different value of k so that the encoding of M = 9 is, C = (2 5 , C2 ), what is the integer C2?, Rule (5) for doing arithmetic in elliptic curves over real numbers states that to double, a point Q2, draw the tangent line and find the other point of intersection S. Then, Q + Q = 2Q = - S. If the tangent line is not vertical, there will be exactly one point, of intersection. However, suppose the tangent line is vertical? In that case, what is the, value 2Q? What is the value 3Q?, Demonstrate that the two elliptic curves of Figure 10.4 each satisfy the conditions for, a group over the real numbers., Is (5, 12) a point on the elliptic curve y2 = x 3 + 4 x - 1 over real numbers?, 17, On the elliptic curve over the real numbers y2 = x3 x + 1, Let P = (0,1) and, 12, Q = (1.5,1.5). Find P + Q and 2P., Does the elliptic curve equation y2 = x 3 + x + 2 define a group over Z7?
Page 339 :
338, , CHAPTER 10 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, 10.12, , 10.13, 10.14, 10.15, , 10.16, , 10.17, , Consider the elliptic curve E7(2,1); that is, the curve is defined by y2 = x 3 + 2 x + 1, with a modulus of p = 7 . Determine all of the points in E7(2, 1). Hint: Start by calculating the right-hand side of the equation for all values of x., What are the negatives of the following elliptic curve points over Z7? P = (3, 5);, Q = (2, 5); R = (5, 0)., For E11(1, 7), consider the point G = (3, 2). Compute the multiple of G from 2G, through 13G., This problem performs elliptic curve encryption/decryption using the scheme outlined in Section 10.4. The cryptosystem parameters are E11(1, 7) and G = (3, 2). B’s, private key is nB = 7., a. Find B’s public key PB., b. A wishes to encrypt the message Pm = (10, 7) and chooses the random value, k = 5. Determine the ciphertext Cm., c. Show the calculation by which B recovers Pm from Cm., The following is a first attempt at an elliptic curve signature scheme. We have a global, elliptic curve, prime p, and “generator” G. Alice picks a private signing key XA and, forms the public verifying key YA = XAG. To sign a message M:, ■, Alice picks a value k., ■, Alice sends Bob M, k, and the signature S = M - kXAG., ■, Bob verifies that M = S + kYA., a. Show that this scheme works. That is, show that the verification process produces, an equality if the signature is valid., b. Show that the scheme is unacceptable by describing a simple technique for forging, a user’s signature on an arbitrary message., Here is an improved version of the scheme given in the previous problem. As before,, we have a global elliptic curve, prime p, and “generator” G. Alice picks a private, signing key XA and forms the public verifying key YA = XAG. To sign a message M:, ■, Bob picks a value k., ■, Bob sends Alice C1 = kG., ■, Alice sends Bob M and the signature S = M - XAC1., ■, Bob verifies that M = S + kYA., a. Show that this scheme works. That is, show that the verification process produces, an equality if the signature is valid., b. Show that forging a message in this scheme is as hard as breaking (Elgamal), elliptic curve cryptography. (Or find an easier way to forge a message?), c. This scheme has an extra “pass” compared to other cryptosystems and signature, schemes we have looked at. What are some drawbacks to this?
Page 340 :
PART FOUR: CRYPTOGRAPHIC DATA, INTEGRITY ALGORITHMS, CHAPTER, , Cryptographic Hash Functions, 11.1 Applications of Cryptographic Hash Functions, Message Authentication, Digital Signatures, Other Applications, 11.2 Two Simple Hash Functions, 11.3 Requirements and Security, Security Requirements for Cryptographic Hash Functions, Brute-Force Attacks, Cryptanalysis, 11.4 Hash Functions Based on Cipher Block Chaining, 11.5 Secure Hash Algorithm (SHA), SHA-512 Logic, SHA-512 Round Function, Example, 11.6 SHA-3, The Sponge Construction, The SHA-3 Iteration Function f, 11.7 Key Terms, Review Questions, and Problems, , 339
Page 341 :
340, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Summarize the applications of cryptographic hash functions., ◆ Explain why a hash function used for message authentication needs to be, secured., ◆ Understand the differences among preimage resistant, second preimage, resistant, and collision resistant properties., ◆ Present an overview of the basic structure of cryptographic hash functions., ◆ Describe how cipher block chaining can be used to construct a hash function., ◆ Understand the operation of SHA-512., ◆ Understand the birthday paradox and present an overview of the birthday, attack., , A hash function H accepts a variable-length block of data M as input and produces, a fixed-size hash value h = H(M). A “good” hash function has the property that the, results of applying the function to a large set of inputs will produce outputs that are, evenly distributed and apparently random. In general terms, the principal object of, a hash function is data integrity. A change to any bit or bits in M results, with high, probability, in a change to the hash value., The kind of hash function needed for security applications is referred to as a, cryptographic hash function. A cryptographic hash function is an algorithm for which, it is computationally infeasible (because no attack is significantly more efficient than, brute force) to find either (a) a data object that maps to a pre-specified hash result, (the one-way property) or (b) two data objects that map to the same hash result (the, collision-free property). Because of these characteristics, hash functions are often used, to determine whether or not data has changed., Figure 11.1 depicts the general operation of a cryptographic hash function., Typically, the input is padded out to an integer multiple of some fixed length, (e.g., 1024 bits), and the padding includes the value of the length of the original message in bits. The length field is a security measure to increase the difficulty for an, attacker to produce an alternative message with the same hash value, as explained, subsequently., This chapter begins with a discussion of the wide variety of applications for, cryptographic hash functions. Next, we look at the security requirements for such, functions. Then we look at the use of cipher block chaining to implement a cryptographic hash function. The remainder of the chapter is devoted to the most important, and widely used family of cryptographic hash functions, the Secure Hash Algorithm, (SHA) family., Appendix N describes MD5, a well-known cryptographic hash function with, similarities to SHA-1.
Page 342 :
11.1 / APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS, , 341, , L bits, , Message or data block M (variable length), , P, L, , H, , Hash value h, (fixed length), , P, L = padding plus length field, , Figure 11.1, , Cryptographic Hash Function; h = H(M), , 11.1 APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS, Perhaps the most versatile cryptographic algorithm is the cryptographic hash function. It is used in a wide variety of security applications and Internet protocols., To better understand some of the requirements and security implications for cryptographic hash functions, it is useful to look at the range of applications in which it, is employed., , Message Authentication, Message authentication is a mechanism or service used to verify the integrity of, a message. Message authentication assures that data received are exactly as sent, (i.e., there is no modification, insertion, deletion, or replay). In many cases, there is, a requirement that the authentication mechanism assures that purported identity of, the sender is valid. When a hash function is used to provide message authentication,, the hash function value is often referred to as a message digest.1, The essence of the use of a hash function for message integrity is as follows., The sender computes a hash value as a function of the bits in the message and transmits both the hash value and the message. The receiver performs the same hash calculation on the message bits and compares this value with the incoming hash value., , 1, , The topic of this section is invariably referred to as message authentication. However, the concepts and, techniques apply equally to data at rest. For example, authentication techniques can be applied to a file, in storage to assure that the file is not tampered with.
Page 343 :
342, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , If there is a mismatch, the receiver knows that the message (or possibly the hash, value) has been altered (Figure 11.2a)., The hash value must be transmitted in a secure fashion. That is, the hash value, must be protected so that if an adversary alters or replaces the message, it is not, feasible for adversary to also alter the hash value to fool the receiver. This type, of attack is shown in Figure 11.2b. In this example, Alice transmits a data block, and attaches a hash value. Darth intercepts the message, alters or replaces the data, block, and calculates and attaches a new hash value. Bob receives the altered data, with the new hash value and does not detect the change. To prevent this attack, the, hash value generated by Alice must be protected., , Bob, , Alice, , data, , data, , H, H, , COMPARE, , data, , (a) Use of hash function to check data integrity, , Alice, , data, , Bob, , Darth, , data, , data, , H, , H, , data, H, , data, , data, , (b) Man-in-the-middle attack, , Figure 11.2 Attack Against Hash Function, , COMPARE
Page 344 :
11.1 / APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS, , 343, , Figure 11.3 illustrates a variety of ways in which a hash code can be used to, provide message authentication, as follows., a. The message plus concatenated hash code is encrypted using symmetric, encryption. Because only A and B share the secret key, the message must have, come from A and has not been altered. The hash code provides the structure or, redundancy required to achieve authentication. Because encryption is applied, to the entire message plus hash code, confidentiality is also provided., b. Only the hash code is encrypted, using symmetric encryption. This reduces the, processing burden for those applications that do not require confidentiality., , Source A, M, , Destination B, ||, , E, , D, , K, , K, , H, M, Compare, , E(K, [M || H(M )]), , H, , H(M ), , (a), , M, , H, , M, , ||, K, H, , K, , E, , M, , D, , E(K, H(M )), , (b), , M, , ||, , Compare, , H, , ||, , S, , Compare, , (c), , S, , ||, , H, , M, , H(M || S), , ||, , E, , D, , M, , S, , ||, , H, Compare, , K, (d), , S, , ||, , H, , E(K, [M || H(M || S)]), , K, H(M || S), , Figure 11.3 Simplified Examples of the Use of a Hash Function for Message Authentication, , Hiva-Network.Com
Page 345 :
344, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , c. It is possible to use a hash function but no encryption for message authentication. The technique assumes that the two communicating parties share a common, secret value S. A computes the hash value over the concatenation of M and S and, appends the resulting hash value to M. Because B possesses S, it can recompute, the hash value to verify. Because the secret value itself is not sent, an opponent, cannot modify an intercepted message and cannot generate a false message., d. Confidentiality can be added to the approach of method (c) by encrypting the, entire message plus the hash code., When confidentiality is not required, method (b) has an advantage over, methods (a) and (d), which encrypts the entire message, in that less computation is required. Nevertheless, there has been growing interest in techniques that, avoid encryption (Figure 11.3c). Several reasons for this interest are pointed out, in [TSUD92]., ■, , ■, , ■, ■, , Encryption software is relatively slow. Even though the amount of data to be, encrypted per message is small, there may be a steady stream of messages into, and out of a system., Encryption hardware costs are not negligible. Low-cost chip implementations, of DES are available, but the cost adds up if all nodes in a network must have, this capability., Encryption hardware is optimized toward large data sizes. For small blocks of, data, a high proportion of the time is spent in initialization/invocation overhead., Encryption algorithms may be covered by patents, and there is a cost associated with licensing their use., , More commonly, message authentication is achieved using a message, authentication code (MAC), also known as a keyed hash function. Typically, MACs, are used between two parties that share a secret key to authenticate information, exchanged between those parties. A MAC function takes as input a secret key and, a data block and produces a hash value, referred to as the MAC, which is associated with the protected message. If the integrity of the message needs to be checked,, the MAC function can be applied to the message and the result compared with the, associated MAC value. An attacker who alters the message will be unable to alter the, associated MAC value without knowledge of the secret key. Note that the verifying, party also knows who the sending party is because no one else knows the secret key., Note that the combination of hashing and encryption results in an overall, function that is, in fact, a MAC (Figure 11.3b). That is, E(K, H(M)) is a function of, a variable-length message M and a secret key K, and it produces a fixed-size output, that is secure against an opponent who does not know the secret key. In practice,, specific MAC algorithms are designed that are generally more efficient than an, encryption algorithm., We discuss MACs in Chapter 12., , Digital Signatures, Another important application, which is similar to the message authentication, application, is the digital signature. The operation of the digital signature is similar, to that of the MAC. In the case of the digital signature, the hash value of a message
Page 346 :
11.1 / APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS, , Source A, , Destination B, , M, , H, , M, , ||, PRa, H, , 345, , PUa, , Compare, , D, , E, E(PRa, H(M )), , (a), , M, , ||, PRa, H, , D, , E, K, , E(K, [M || E(PRa, H(M ))]), , E, , (b), , H, M, , K, E(PRa, H(M )), , PUa, , Compare, , D, , Figure 11.4 Simplified Examples of Digital Signatures, , is encrypted with a user’s private key. Anyone who knows the user’s public key can, verify the integrity of the message that is associated with the digital signature. In, this case, an attacker who wishes to alter the message would need to know the user’s, private key. As we shall see in Chapter 14, the implications of digital signatures go, beyond just message authentication., Figure 11.4 illustrates, in a simplified fashion, how a hash code is used to, provide a digital signature., a. The hash code is encrypted, using public-key encryption with the sender’s, private key. As with Figure 11.3b, this provides authentication. It also provides, a digital signature, because only the sender could have produced the encrypted, hash code. In fact, this is the essence of the digital signature technique., b. If confidentiality as well as a digital signature is desired, then the message, plus the private-key-encrypted hash code can be encrypted using a symmetric, secret key. This is a common technique., , Other Applications, Hash functions are commonly used to create a one-way password file. Chapter 21, explains a scheme in which a hash of a password is stored by an operating system, rather than the password itself. Thus, the actual password is not retrievable by a, hacker who gains access to the password file. In simple terms, when a user enters a, password, the hash of that password is compared to the stored hash value for verification. This approach to password protection is used by most operating systems., Hash functions can be used for intrusion detection and virus detection. Store, H(F) for each file on a system and secure the hash values (e.g., on a CD-R that is
Page 347 :
346, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , kept secure). One can later determine if a file has been modified by recomputing, H(F). An intruder would need to change F without changing H(F)., A cryptographic hash function can be used to construct a pseudorandom, function (PRF) or a pseudorandom number generator (PRNG). A common, application for a hash-based PRF is for the generation of symmetric keys. We discuss, this application in Chapter 12., , 11.2 TWO SIMPLE HASH FUNCTIONS, To get some feel for the security considerations involved in cryptographic hash, functions, we present two simple, insecure hash functions in this section. All hash, functions operate using the following general principles. The input (message, file,, etc.) is viewed as a sequence of n -bit blocks. The input is processed one block at a, time in an iterative fashion to produce an n-bit hash function., One of the simplest hash functions is the bit-by-bit exclusive-OR (XOR) of, every block. This can be expressed as, Ci = bi1 ⊕ bi2 ⊕ g ⊕ bim, where, Ci, m, bij, ⊕, , =, =, =, =, , ith bit of the hash code, 1 … i … n, number of n@bit blocks in the input, ith bit in jth block, XOR operation, , This operation produces a simple parity bit for each bit position and is known, as a longitudinal redundancy check. It is reasonably effective for random data as a, data integrity check. Each n-bit hash value is equally likely. Thus, the probability, that a data error will result in an unchanged hash value is 2-n. With more predictably formatted data, the function is less effective. For example, in most normal text, files, the high-order bit of each octet is always zero. So if a 128-bit hash value is, used, instead of an effectiveness of 2-128, the hash function on this type of data has, an effectiveness of 2-112., A simple way to improve matters is to perform a one-bit circular shift, or, rotation, on the hash value after each block is processed. The procedure can be, summarized as follows., 1. Initially set the n-bit hash value to zero., 2. Process each successive n-bit block of data as follows:, a. Rotate the current hash value to the left by one bit., b. XOR the block into the hash value., This has the effect of “randomizing” the input more completely and overcoming, any regularities that appear in the input. Figure 11.5 illustrates these two types of, hash functions for 16-bit hash values.
Page 348 :
11.2 / TWO SIMPLE HASH FUNCTIONS, , 347, , 16 bits, , XOR with 1-bit r otation to the right, , XOR of every 16-bit block, , Figure 11.5 Two Simple Hash Functions, , Although the second procedure provides a good measure of data integrity, it is, virtually useless for data security when an encrypted hash code is used with a plaintext message, as in Figures 11.3b and 11.4a. Given a message, it is an easy matter, to produce a new message that yields that hash code: Simply prepare the desired, alternate message and then append an n-bit block that forces the new message plus, block to yield the desired hash code., Although a simple XOR or rotated XOR (RXOR) is insufficient if only the, hash code is encrypted, you may still feel that such a simple function could be, useful when the message together with the hash code is encrypted (Figure 11.3a)., But you must be careful. A technique originally proposed by the National, Bureau of Standards used the simple XOR applied to 64-bit blocks of the message and then an encryption of the entire message that used the cipher block, chaining (CBC) mode. We can define the scheme as follows: Given a message M, consisting of a sequence of 64-bit blocks X1, X2, c , XN, define the hash code
Page 349 :
348, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , h = H(M) as the block-by-block XOR of all blocks and append the hash code as, the final block:, h = XN + 1 = X1 ⊕ X2 ⊕ c ⊕ XN, Next, encrypt the entire message plus hash code using CBC mode to produce the, encrypted message Y1, Y2, c , YN + 1. [JUEN85] points out several ways in which, the ciphertext of this message can be manipulated in such a way that it is not detectable by the hash code. For example, by the definition of CBC (Figure 6.4), we have, X1 = IV ⊕ D(K,Y1), Xi = Yi - 1 ⊕ D(K, Yi), XN + 1 = YN ⊕ D(K, YN + 1), But XN + 1 is the hash code:, XN + 1 = X1 ⊕ X2 ⊕ c ⊕ XN, = [IV ⊕ D(K, Y1)] ⊕ [Y1 ⊕ D(K, Y2)] ⊕ c ⊕ [YN - 1 ⊕ D(K, YN)], Because the terms in the preceding equation can be XORed in any order, it follows, that the hash code would not change if the ciphertext blocks were permuted., , 11.3 REQUIREMENTS AND SECURITY, Before proceeding, we need to define two terms. For a hash value h = H(x), we, say that x is the preimage of h. That is, x is a data block whose hash value, using the, function H, is h. Because H is a many-to-one mapping, for any given hash value h,, there will in general be multiple preimages. A collision occurs if we have x ≠ y and, H(x) = H(y). Because we are using hash functions for data integrity, collisions are, clearly undesirable., Let us consider how many preimages are there for a given hash value, which is, a measure of the number of potential collisions for a given hash value. Suppose the, length of the hash code is n bits, and the function H takes as input messages or data, blocks of length b bits with b 7 n. Then, the total number of possible messages is, 2b and the total number of possible hash values is 2n. On average, each hash value, corresponds to 2b - n preimages. If H tends to uniformly distribute hash values then,, in fact, each hash value will have close to 2b - n preimages. If we now allow inputs, of arbitrary length, not just a fixed length of some number of bits, then the number, of preimages per hash value is arbitrarily large. However, the security risks in the, use of a hash function are not as severe as they might appear from this analysis., To understand better the security implications of cryptographic hash functions, we, need precisely define their security requirements., , Security Requirements for Cryptographic Hash Functions, Table 11.1 lists the generally accepted requirements for a cryptographic hash function. The first three properties are requirements for the practical application of a, hash function.
Page 350 :
11.3 / REQUIREMENTS AND SECURITY, Table 11.1, , 349, , Requirements for a Cryptographic Hash Function H, Requirement, , Description, , Variable input size, , H can be applied to a block of data of any size., , Fixed output size, , H produces a fixed-length output., , Efficiency, , H(x) is relatively easy to compute for any, given x, making both hardware and software, implementations practical., , Preimage resistant (one-way property), , For any given hash value h, it is computationally, infeasible to find y such that H(y) = h., , Second preimage resistant (weak collision, resistant), , For any given block x, it is computationally, infeasible to find y ≠ x with H(y) = H(x)., , Collision resistant (strong collision resistant), , It is computationally infeasible to find any pair, (x, y) with x ≠ y, such that H(x) = H(y)., , Pseudorandomness, , Output of H meets standard tests for, pseudorandomness., , The fourth property, preimage resistant, is the one-way property: it is easy, to generate a code given a message, but virtually impossible to generate a message, given a code. This property is important if the authentication technique involves the, use of a secret value (Figure 11.3c). The secret value itself is not sent. However, if, the hash function is not one way, an attacker can easily discover the secret value:, If the attacker can observe or intercept a transmission, the attacker obtains the, message M, and the hash code h = H(S } M). The attacker then inverts the hash, function to obtain S } M = H-1(MDM). Because the attacker now has both M and, SAB } M, it is a trivial matter to recover SAB., The fifth property, second preimage resistant, guarantees that it is infeasible to, find an alternative message with the same hash value as a given message. This prevents forgery when an encrypted hash code is used (Figures 11.3b and 11.4a). If this, property were not true, an attacker would be capable of the following sequence:, First, observe or intercept a message plus its encrypted hash code; second, generate, an unencrypted hash code from the message; third, generate an alternate message, with the same hash code., A hash function that satisfies the first five properties in Table 11.1 is referred, to as a weak hash function. If the sixth property, collision resistant, is also satisfied, then it is referred to as a strong hash function. A strong hash function protects, against an attack in which one party generates a message for another party to sign., For example, suppose Bob writes an IOU message, sends it to Alice, and she signs, it. Bob finds two messages with the same hash, one of which requires Alice to pay a, small amount and one that requires a large payment. Alice signs the first message,, and Bob is then able to claim that the second message is authentic., Figure 11.6 shows the relationships among the three resistant properties., A function that is collision resistant is also second preimage resistant, but the, reverse is not necessarily true. A function can be collision resistant but not preimage resistant and vice versa. A function can be preimage resistant but not second, preimage resistant and vice versa. See [MENE97] for a discussion.
Page 351 :
350, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, Second, preimage resistant, , Preimage, resistant, , Collision, resistant, , Figure 11.6 Relationship Among Hash Function Properties, Table 11.2, , Hash Function Resistance Properties Required for Various Data Integrity Applications, Preimage Resistant, , Second Preimage, Resistant, , Collision Resistant, , yes, , yes, , yes*, , Hash + digital signature, Intrusion detection and virus, detection, , yes, , Hash + symmetric encryption, One-way password file, , yes, , MAC, , yes, , yes, , yes*, , *Resistance required if attacker is able to mount a chosen message attack, , Table 11.2 shows the resistant properties required for various hash function, applications., The final requirement in Table 11.1, pseudorandomness, has not traditionally been listed as a requirement of cryptographic hash functions but is more or, less implied. [JOHN05] points out that cryptographic hash functions are commonly, used for key derivation and pseudorandom number generation, and that in message, integrity applications, the three resistant properties depend on the output of the, hash function appearing to be random. Thus, it makes sense to verify that in fact a, given hash function produces pseudorandom output., , Brute-Force Attacks, As with encryption algorithms, there are two categories of attacks on hash functions: brute-force attacks and cryptanalysis. A brute-force attack does not depend, on the specific algorithm but depends only on bit length. In the case of a hash function, a brute-force attack depends only on the bit length of the hash value. A cryptanalysis, in contrast, is an attack based on weaknesses in a particular cryptographic, algorithm. We look first at brute-force attacks.
Page 352 :
11.3 / REQUIREMENTS AND SECURITY, , 351, , PREIMAGE AND SECOND PREIMAGE ATTACKS For a preimage or second preimage, attack, an adversary wishes to find a value y such that H(y) is equal to a given hash, value h. The brute-force method is to pick values of y at random and try each value, until a collision occurs. For an m-bit hash value, the level of effort is proportional, to 2m. Specifically, the adversary would have to try, on average, 2m - 1 values of y to, find one that generates a given hash value h. This result is derived in Appendix U, [Equation (U.1)]., COLLISION RESISTANT ATTACKS For a collision resistant attack, an adversary wishes, to find two messages or data blocks, x and y, that yield the same hash function:, H(x) = H(y). This turns out to require considerably less effort than a preimage or, second preimage attack. The effort required is explained by a mathematical result, referred to as the birthday paradox. In essence, if we choose random variables from, a uniform distribution in the range 0 through N - 1, then the probability that a, repeated element is encountered exceeds 0.5 after 2N choices have been made., Thus, for an m-bit hash value, if we pick data blocks at random, we can expect to, find two data blocks with the same hash value within 22m = 2m/2 attempts. The, mathematical derivation of this result is found in Appendix U., Yuval proposed the following strategy to exploit the birthday paradox in a, collision resistant attack [YUVA79]., 1. The source, A, is prepared to sign a legitimate message x by appending the, appropriate m-bit hash code and encrypting that hash code with A’s private, key (Figure 11.4a)., 2. The opponent generates 2m/2 variations x′ of x, all of which convey essentially, the same meaning, and stores the messages and their hash values., 3. The opponent prepares a fraudulent message y for which A’s signature is, desired., 4. The opponent generates minor variations y′ of y, all of which convey essentially the same meaning. For each y′, the opponent computes H(y′), checks, for matches with any of the H(x′) values, and continues until a match is found., That is, the process continues until a y′ is generated with a hash value equal to, the hash value of one of the x′ values., 5. The opponent offers the valid variation to A for signature. This signature can, then be attached to the fraudulent variation for transmission to the intended, recipient. Because the two variations have the same hash code, they will produce the same signature; the opponent is assured of success even though the, encryption key is not known., Thus, if a 64-bit hash code is used, the level of effort required is only on the, order of 232 [see Appendix U, Equation (U.7)]., The generation of many variations that convey the same meaning is not difficult. For example, the opponent could insert a number of “space-space-backspace”, character pairs between words throughout the document. Variations could then, be generated by substituting “space-backspace-space” in selected instances.
Page 353 :
352, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , Alternatively, the opponent could simply reword the message but retain the, meaning. Figure 11.7 provides an example., To summarize, for a hash code of length m, the level of effort required, as we, have seen, is proportional to the following., Preimage resistant, , 2m, , Second preimage resistant, , 2m, , Collision resistant, , 2m/2, , the, —, , As, , Cherise, , known, , Rosetti for the, , our, the, , had the pleasure of knowing, , Dean of Blakewell College, I have, , last, past, , school. I, , would like to take this opportunity to, , asset to, role model in, , recommend Cherise for your, , wholeheartedly, , school’s graduate program. I, —, , thus far her grades, , have been, are, , her grades thus far, , confident, certain, , am, feel, , continue to succeed in her studies., —, , She, Cherise, , has proven to be a take-charge, has been, successfully develop plans and implement them., , She, has also assisted, Cherise, , us, —, , that, —, , she, Cherise, , will, , is a dedicated student and, , exemplary . In class,, excellent, , she, Cherise, , successfully, , a tremendous, an outstanding, , has been, was, , four years. She, , person, individual, , in our admissions office., , who is, —, , She, Cherise, , able to, , has, , demonstrated leadership ability by counseling new and prospective students., , —, Her, Cherise’s, have, , advice has been, , a great, , taken time to share their comments with me regarding her pleasant and, shared, , encouraging, , attitude., , reassuring, , For these reasons, It is for these reasons that, , highly recommend, offer high recommendations for, , abilities will, potential, , truly, surely, , be an, , Cherise, , asset to, plus for, , Figure 11.7 A Letter in 238 Variations, , Hiva-Network.Com, , help to these students, many of whom, , of considerable, , I, , without reservation, . Her, unreservedly, , your, , establishment ., school, , ambition and, drive
Page 354 :
11.3 / REQUIREMENTS AND SECURITY, , 353, , If collision resistance is required (and this is desirable for a general-purpose, secure hash code), then the value 2m/2 determines the strength of the hash code, against brute-force attacks. Van Oorschot and Wiener [VANO94] presented, a design for a $10 million collision search machine for MD5, which has a 128-bit hash, length, that could find a collision in 24 days. Thus, a 128-bit code may be viewed as, inadequate. The next step up, if a hash code is treated as a sequence of 32 bits,, is a 160-bit hash length. With a hash length of 160 bits, the same search machine, would require over four thousand years to find a collision. With today’s technology,, the time would be much shorter, so that 160 bits now appears suspect., , Cryptanalysis, As with encryption algorithms, cryptanalytic attacks on hash functions seek to, exploit some property of the algorithm to perform some attack other than an, exhaustive search. The way to measure the resistance of a hash algorithm to cryptanalysis is to compare its strength to the effort required for a brute-force attack., That is, an ideal hash algorithm will require a cryptanalytic effort greater than or, equal to the brute-force effort., In recent years, there has been considerable effort, and some successes,, in developing cryptanalytic attacks on hash functions. To understand these, we, need to look at the overall structure of a typical secure hash function, indicated, in Figure 11.8. This structure, referred to as an iterated hash function, was proposed by Merkle [MERK79, MERK89] and is the structure of most hash functions in use today, including SHA, which is discussed later in this chapter. The, hash function takes an input message and partitions it into L fixed-sized blocks, of b bits each. If necessary, the final block is padded to b bits. The final block, also includes the value of the total length of the input to the hash function. The, inclusion of the length makes the job of the opponent more difficult. Either the, opponent must find two messages of equal length that hash to the same value or, two messages of differing lengths that, together with their length values, hash to, the same value., , Y0, , Y1, , b, , IV =, CV0, , b, , f, , n, , n, , b, , f, , n, , n, , CVL–1, , CV1, IV, CVi, Yi, f, , Figure 11.8, , YL–1, , = Initial value, = Chaining variable, = ith input block, = Compression algorithm, , L = Number of input blocks, n = Length of hash code, b = Length of input block, , General Structure of Secure Hash Code, , f, , n, , CVL
Page 355 :
354, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , The hash algorithm involves repeated use of a compression function, f, that, takes two inputs (an n-bit input from the previous step, called the chaining variable,, and a b-bit block) and produces an n-bit output. At the start of hashing, the chaining, variable has an initial value that is specified as part of the algorithm. The final value, of the chaining variable is the hash value. Often, b 7 n; hence the term compression., The hash function can be summarized as, CV0 = IV = initial n@bit value, CVi = f(CVi - 1, Yi - 1) 1 … i … L, H(M) = CVL, where the input to the hash function is a message M consisting of the blocks, Y0, Y1, c , YL - 1., The motivation for this iterative structure stems from the observation by, Merkle [MERK89] and Damgard [DAMG89] that if the length field is included in, the input, and if the compression function is collision resistant, then so is the resultant iterated hash function.2 Therefore, the structure can be used to produce, a secure hash function to operate on a message of any length. The problem of, designing a secure hash function reduces to that of designing a collision-resistant, compression function that operates on inputs of some fixed size., Cryptanalysis of hash functions focuses on the internal structure of f and is, based on attempts to find efficient techniques for producing collisions for a single, execution of f. Once that is done, the attack must take into account the fixed value, of IV. The attack on f depends on exploiting its internal structure. Typically, as with, symmetric block ciphers, f consists of a series of rounds of processing, so that the, attack involves analysis of the pattern of bit changes from round to round., Keep in mind that for any hash function there must exist collisions, because, we are mapping a message of length at least equal to twice the block size b (because, we must append a length field) into a hash code of length n, where b Ú n. What is, required is that it is computationally infeasible to find collisions., The attacks that have been mounted on hash functions are rather complex and, beyond our scope here. For the interested reader, [DOBB96] and [BELL97] are, recommended., , 11.4 HASH FUNCTIONS BASED ON CIPHER BLOCK CHAINING, A number of proposals have been made for hash functions based on using a cipher, block chaining technique, but without using the secret key. One of the first such, proposals was that of Rabin [RABI78]. Divide a message M into fixed-size blocks, M1, M2, c , MN and use a symmetric encryption system such as DES to compute, the hash code G as, H0 = initial value, Hi = E(Mi, Hi - 1), G = HN, 2, , The converse is not necessarily true.
Page 356 :
11.5 / SECURE HASH ALGORITHM (SHA), , 355, , This is similar to the CBC technique, but in this case, there is no secret key. As with, any hash code, this scheme is subject to the birthday attack, and if the encryption algorithm is DES and only a 64-bit hash code is produced, then the system, is vulnerable., Furthermore, another version of the birthday attack can be used even if the, opponent has access to only one message and its valid signature and cannot obtain, multiple signings. Here is the scenario: We assume that the opponent intercepts, a message with a signature in the form of an encrypted hash code and that the, unencrypted hash code is m bits long., 1. Use the algorithm defined at the beginning of this subsection to calculate the, unencrypted hash code G., 2. Construct any desired message in the form Q1, Q2, c , QN - 2., 3. Compute Hi = E(Qi, Hi - 1) for 1 … i … (N - 2)., 4. Generate 2m/2 random blocks; for each block X, compute E(X, HN - 2)., Generate an additional 2m/2 random blocks; for each block Y, compute D(Y,, G), where D is the decryption function corresponding to E., 5. Based on the birthday paradox, with high probability there will be an X and Y, such that E(X, HN - 2) = D(Y, G)., 6. Form the message Q1, Q2, c , QN - 2, X, Y. This message has the hash code G, and therefore can be used with the intercepted encrypted signature., This form of attack is known as a meet-in-the-middle-attack. A number of, researchers have proposed refinements intended to strengthen the basic block, chaining approach. For example, Davies and Price [DAVI89] describe the variation:, Hi = E(Mi, H i - 1) ⊕ Hi - 1, Another variation, proposed in [MEYE88], is, Hi = E(Hi - 1, Mi) ⊕ Mi, However, both of these schemes have been shown to be vulnerable to a variety, of attacks [MIYA90]. More generally, it can be shown that some form of birthday, attack will succeed against any hash scheme involving the use of cipher block chaining without a secret key, provided that either the resulting hash code is small enough, (e.g., 64 bits or less) or that a larger hash code can be decomposed into independent, subcodes [JUEN87]., Thus, attention has been directed at finding other approaches to hashing., Many of these have also been shown to have weaknesses [MITC92]., , 11.5 SECURE HASH ALGORITHM (SHA), In recent years, the most widely used hash function has been the Secure Hash, Algorithm (SHA). Indeed, because virtually every other widely used hash function, had been found to have substantial cryptanalytic weaknesses, SHA was more or, less the last remaining standardized hash algorithm by 2005. SHA was developed
Page 357 :
356, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, Table 11.3, , Comparison of SHA Parameters, Message Size, , Block Size, , Word Size, , Message, Digest Size, , SHA-1, , 6 264, , 512, , 32, , 160, , SHA-224, , 6 264, , 512, , 32, , 224, , SHA-256, , 6 264, , 512, , 32, , 256, , SHA-384, , 6 2128, , 1024, , 64, , 384, , SHA-512, , 6 2128, , 1024, , 64, , 512, , SHA-512/224, , 6 2128, , 1024, , 64, , 224, , SHA-512/256, , 6 2128, , 1024, , 64, , 256, , Algorithm, , Note: All sizes are measured in bits., , by the National Institute of Standards and Technology (NIST) and published as a, federal information processing standard (FIPS 180) in 1993. When weaknesses were, discovered in SHA, now known as SHA-0, a revised version was issued as FIPS, 180-1 in 1995 and is referred to as SHA-1. The actual standards document is entitled, “Secure Hash Standard.” SHA is based on the hash function MD4, and its design, closely models MD4., SHA-1 produces a hash value of 160 bits. In 2002, NIST produced a revised, version of the standard, FIPS 180-2, that defined three new versions of SHA, with, hash value lengths of 256, 384, and 512 bits, known as SHA-256, SHA-384, and, SHA-512, respectively. Collectively, these hash algorithms are known as SHA-2., These new versions have the same underlying structure and use the same types of, modular arithmetic and logical binary operations as SHA-1. A revised document, was issued as FIP PUB 180-3 in 2008, which added a 224-bit version (Table 11.3)., In 2015, NIST issued FIPS 180-4, which added two additional algorithms:, SHA-512/224 and SHA-512/256. SHA-1 and SHA-2 are also specified in RFC, 6234, which essentially duplicates the material in FIPS 180-3 but adds a C code, implementation., In 2005, NIST announced the intention to phase out approval of SHA-1 and, move to a reliance on SHA-2 by 2010. Shortly thereafter, a research team described, an attack in which two separate messages could be found that deliver the same, SHA-1 hash using 269 operations, far fewer than the 280 operations previously, thought needed to find a collision with an SHA-1 hash [WANG05]. This result, should hasten the transition to SHA-2., In this section, we provide a description of SHA-512. The other versions are, quite similar., , SHA-512 Logic, The algorithm takes as input a message with a maximum length of less than 2128 bits, and produces as output a 512-bit message digest. The input is processed in 1024-bit, blocks. Figure 11.9 depicts the overall processing of a message to produce a digest.
Page 358 :
11.5 / SECURE HASH ALGORITHM (SHA), , 357, , N 1024 bits, 128 bits, , L bits, , Message, , 1024 bits, , IV = H0, 512 bits, , 1000000, . . . ,0 L, , 1024 bits, , 1024 bits, , M1, , M2, , MN, , F, , F, , F, , +, , +, , +, , H1, , H2, , 512 bits, , HN, hash code, , 512 bits, , + = word-by-word addition mod 264, Figure 11.9, , Message Digest Generation Using SHA-512, , This follows the general structure depicted in Figure 11.8. The processing consists, of the following steps., Step 1 Append padding bits. The message is padded so that its length is congruent, to 896 modulo 1024 [length K 896(mod 1024)]. Padding is always added,, even if the message is already of the desired length. Thus, the number of, padding bits is in the range of 1 to 1024. The padding consists of a single 1 bit, followed by the necessary number of 0 bits., Step 2 Append length. A block of 128 bits is appended to the message. This block, is treated as an unsigned 128-bit integer (most significant byte first) and, contains the length of the original message in bits (before the padding)., The outcome of the first two steps yields a message that is an integer, multiple of 1024 bits in length. In Figure 11.9, the expanded message is represented as the sequence of 1024-bit blocks M1, M2, c , MN, so that the, total length of the expanded message is N * 1024 bits., Step 3 Initialize hash buffer. A 512-bit buffer is used to hold intermediate and final, results of the hash function. The buffer can be represented as eight 64-bit, registers (a, b, c, d, e, f, g, h). These registers are initialized to the following, 64-bit integers (hexadecimal values):, a = 6A09E667F3BCC908, , e = 510E527FADE682D1, , b = BB67AE8584CAA73B, , f = 9B05688C2B3E6C1F, , c = 3C6EF372FE94F82B, , g = 1F83D9ABFB41BD6B, , d = A54FF53A5F1D36F1, , h = 5BE0CD19137E2179
Page 359 :
358, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , These values are stored in big-endian format, which is the most significant, byte of a word in the low-address (leftmost) byte position. These words, were obtained by taking the first sixty-four bits of the fractional parts of the, square roots of the first eight prime numbers., Step 4 Process message in 1024-bit (128-byte) blocks. The heart of the algorithm is, a module that consists of 80 rounds; this module is labeled F in Figure 11.9., The logic is illustrated in Figure 11.10., Each round takes as input the 512-bit buffer value, abcdefgh, and, updates the contents of the buffer. At input to the first round, the buffer, has the value of the intermediate hash value, Hi - 1. Each round t makes, use of a 64-bit value Wt, derived from the current 1024-bit block being processed (Mi). These values are derived using a message schedule described, subsequently. Each round also makes use of an additive constant Kt, where, 0 … t … 79 indicates one of the 80 rounds. These words represent the first, 64 bits of the fractional parts of the cube roots of the first 80 prime numbers., The constants provide a “randomized” set of 64-bit patterns, which should, eliminate any regularities in the input data. Table 11.4 shows these constants, in hexadecimal format (from left to right)., , Mi, , Hi–1, , Message, schedule, , a, , b, , c, , W0, , d, , e, , f, , g, , 64, h, K0, , Round 0, , a, , b, , c, , Wt, , d, , e, , f, , g, , h, Kt, , Round t, , a, , b, , c, , W79, , d, , e, , f, , g, , h, K79, , Round 79, , +, , +, , +, , +, , +, , +, , +, , +, , Hi, , Figure 11.10 SHA-512 Processing of a Single 1024-Bit Block
Page 361 :
360, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , SHA-512 Round Function, Let us look in more detail at the logic in each of the 80 steps of the processing, of one 512-bit block (Figure 11.11). Each round is defined by the following set of, equations:, T1 = h + Ch(e, f, g) + ( a 512, 1 e) + Wt + Kt, T2 = ( a 512, a), +, Maj(a,, b, c), 0, h = g, g = f, f = e, e = d + T1, d = c, c = b, b = a, a = T1 + T2, where, = step number; 0 … t … 79, = (e AND f) ⊕ (NOT e AND g), the conditional function: If e then f else g, Maj(a, b, c) = (a AND b) ⊕ (a AND c) ⊕ (b AND c), the function is true only of the majority (two or three) of the, arguments are true, 512, (Σ 0 a), = ROTR28(a) ⊕ ROTR34(a) ⊕ ROTR39(a), 512, (Σ 1 e), = ROTR14(e) ⊕ ROTR18(e) ⊕ ROTR41(e), ROTRn(x) = circular right shift (rotation) of the 64-bit argument x by n bits, t, Ch(e, f, g), , a, , b, , c, , d, , e, , g, , f, , Maj, , h, +, , Ch, , +, +, +, , +, , Wt, , +, , Kt, , +, , a, , b, , c, , d, , e, , f, , g, , h, , 512 bits, , Figure 11.11, , Elementary SHA-512 Operation (single round)
Page 362 :
11.5 / SECURE HASH ALGORITHM (SHA), , 361, , Wt = a 64-bit word derived from the current 1024-bit input block, Kt = a 64-bit additive constant, + = addition modulo 264, Two observations can be made about the round function., 1. Six of the eight words of the output of the round function involve simply permutation (b, c, d, f, g, h) by means of rotation. This is indicated by shading in, Figure 11.11., 2. Only two of the output words (a, e) are generated by substitution. Word e is a, function of input variables (d, e, f, g, h), as well as the round word Wt and the, constant Kt. Word a is a function of all of the input variables except d, as well, as the round word Wt and the constant Kt., It remains to indicate how the 64-bit word values Wt are derived from the, 1024-bit message. Figure 11.12 illustrates the mapping. The first 16 values of Wt are, taken directly from the 16 words of the current block. The remaining values are, defined as, 512, Wt = s512, 1 (Wt - 2) + Wt - 7 + s0 (Wt - 15) + Wt - 16, , where, s512, 0 (x), s512, 1 (x), ROTRn(x), SHRn(x), , =, =, =, =, , ROTR1(x) ⊕ ROTR8(x) ⊕ SHR7(x), ROTR19(x) ⊕ ROTR61(x) ⊕ SHR6(x), circular right shift (rotation) of the 64-bit argument x by n bits, right shift of the 64-bit argument x by n bits with padding by zeros on, the left, + = addition modulo 264, , Thus, in the first 16 steps of processing, the value of Wt is equal to the corresponding word in the message block. For the remaining 64 steps, the value of, Wt consists of the circular left shift by one bit of the XOR of four of the preceding values of Wt, with two of those values subjected to shift and rotate operations., W0, , 1024 bits, , Mi, , W1, , W9 W14, , s0 s1, , +, W0, , W1, , W15, , W16, , Wt–16 Wt–15 Wt–7 Wt–2, , W63 W64 W72 W77, , s0 s1, , +, Wt, , 64 bits, , Figure 11.12 Creation of 80-word Input Sequence for SHA-512 Processing of Single Block, , Hiva-Network.Com, , s0 s1, , +, W79
Page 363 :
362, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , This introduces a great deal of redundancy and interdependence into the message, blocks that are compressed, which complicates the task of finding a different, message block that maps to the same compression function output. Figure 11.13, summarizes the SHA-512 logic., The SHA-512 algorithm has the property that every bit of the hash code is a, function of every bit of the input. The complex repetition of the basic function F, produces results that are well mixed; that is, it is unlikely that two messages chosen at random, even if they exhibit similar regularities, will have the same hash, code. Unless there is some hidden weakness in SHA-512, which has not so far been, published, the difficulty of coming up with two messages having the same message, digest is on the order of 2256 operations, while the difficulty of finding a message, with a given digest is on the order of 2512 operations., , Example, We include here an example based on one in FIPS 180. We wish to hash a one-block, message consisting of three ASCII characters: “abc,” which is equivalent to the, following 24-bit binary string:, 01100001 01100010 01100011, Recall from step 1 of the SHA algorithm, that the message is padded to a, length congruent to 896 modulo 1024. In this case of a single block, the padding, consists of 896 - 24 = 872 bits, consisting of a “1” bit followed by 871 “0” bits., Then a 128-bit length value is appended to the message, which contains the length, of the original message in bits (before the padding). The original length is 24 bits,, or a hexadecimal value of 18. Putting this all together, the 1024-bit message block,, in hexadecimal, is, 6162638000000000, 0000000000000000, 0000000000000000, 0000000000000000, , 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, , 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, , 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000018, , This block is assigned to the words W0, . . . , W15 of the message schedule,, which appears as follows., W0, W1, W2, W3, W4, W5, W6, W7, , =, =, =, =, =, =, =, =, , 6162638000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, , W8, W9, W10, W11, W12, W13, W14, W15, , =, =, =, =, =, =, =, =, , 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000018
Page 364 :
11.5 / SECURE HASH ALGORITHM (SHA), , The padded message consists blocks M1, M2, c , MN. Each message, block Mi consists of 16 64-bit words Mi,0, Mi,1, c , Mi,15. All addition, is performed modulo 264., H0,0, H0,1, H0,2, H0,3, , =, =, =, =, , 6A09E667F3BCC908, BB67AE8584CAA73B, 3C6EF372FE94F82B, A54FF53A5F1D36F1, , H0,4, H0,5, H0,6, H0,7, , =, =, =, =, , 510E527FADE682D1, 9B05688C2B3E6C1F, 1F83D9ABFB41BD6B, 5BE0CD19137E2179, , for i = 1 to N, 1. Prepare the message schedule W, for t = 0 to 15, Wt = Mi,t, for t = 16 to 79, 512, Wt = s512, 1 (Wt - 2) + Wt - 7 + s0 (Wt - 15) + Wt - 16, 2. Initialize the working variables, a = Hi - 1, 0, e = Hi - 1, 4, b = Hi - 1, 1, f = Hi - 1, 5, c = Hi - 1, 2, g = Hi - 1, 6, d = Hi - 1, 3, h = Hi - 1, 7, 3. Perform the main hash computation, for t = 0 to 79, T1 = h + Ch(e, f, g) + ¢ Σ 512, 1 e≤ + Wt + Kt, T2 = ¢ Σ 512, 0 a≤ + Maj(a, b, c), h = g, g = f, f = e, e = d + T1, d = c, c = b, b = a, a = T1 + T2, 4. Compute the intermediate hash value, Hi, 0 = a + Hi - 1, 0, Hi, 4 = e + Hi - 1,4, Hi, 1 = b + Hi - 1, 1, Hi, 5 = f + Hi - 1, 5, Hi, 2 = c + Hi - 1, 2, Hi, 6 = g + Hi - 1, 6, Hi, 3 = d + Hi - 1, 3, Hi, 7 = h + Hi - 1, 7, return {HN, 0 } HN, 1 } HN, 2 } HN, 3 } HN, 4 } HN, 5 } HN, 6 } HN, 7}, Figure 11.13, , SHA-512 Logic, , 363
Page 366 :
11.6 / SHA-3, , 365, , 11.6 SHA-3, As of this writing, the Secure Hash Algorithm (SHA-1) has not yet been “broken.”, That is, no one has demonstrated a technique for producing collisions in a practical, amount of time. However, because SHA-1 is very similar, in structure and in the, basic mathematical operations used, to MD5 and SHA-0, both of which have been, broken, SHA-1 is considered insecure and has been phased out for SHA-2., SHA-2, particularly the 512-bit version, would appear to provide unassailable, security. However, SHA-2 shares the same structure and mathematical operations, as its predecessors, and this is a cause for concern. Because it will take years to find, a suitable replacement for SHA-2, should it become vulnerable, NIST decided to, begin the process of developing a new hash standard., Accordingly, NIST announced in 2007 a competition to produce the next generation NIST hash function, to be called SHA-3. The winning design for SHA-3, was announced by NIST in October 2012 and published as FIP 102 in August 2015., SHA-3 is a cryptographic hash function that is intended to complement SHA-2 as, the approved standard for a wide range of applications., Appendix V looks at the evaluation criteria used by NIST to select from, among the candidates for AES, plus the rationale for picking Keccak, which was, the winning candidate. This material is useful in understanding not just the SHA-3, design but also the criteria by which to judge any cryptographic hash algorithm., , The Sponge Construction, The underlying structure of SHA-3 is a scheme referred to by its designers as a, sponge construction [BERT07, BERT11]. The sponge construction has the same, general structure as other iterated hash functions (Figure 11.8). The sponge function takes an input message and partitions it into fixed-size blocks. Each block is, processed in turn with the output of each iteration fed into the next iteration, finally, producing an output block., The sponge function is defined by three parameters:, f = the internal function used to process each input block3, r = the size in bits of the input blocks, called the bitrate, pad = the padding algorithm, A sponge function allows both variable length input and output, making it a, flexible structure that can be used for a hash function (fixed-length output), a pseudorandom number generator (fixed-length input), and other cryptographic functions. Figure 11.14 illustrates this point. An input message of n bits is partitioned, into k fixed-size blocks of r bits each. The message is padded to achieve a length, that is an integer multiple of r bits. The resulting partition is the sequence of blocks, P0, P1, c , Pk - 1, with length k * r. For uniformity, padding is always added, so, , 3, The Keccak documentation refers to f as a permutation. As we shall see, it involves both permutations, and substitutions. We refer to f as the iteration function, because it is the function that is executed once, for each iteration, that is, once for each block of the message that is processed.
Page 367 :
366, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, k, , r bits, , n bits, , message, , r bits, , P0, , pad, , r bits, , r bits, , P1, , Pk–1, , (a) Input, l bits, r bits, , Z0, , r bits, , r bits, , Z1, Zj–1, , (b) Output, Figure 11.14, , Sponge Function Input and Output, , that if n mod r = 0, a padding block of r bits is added. The actual padding algorithm, is a parameter of the function. The sponge specification [BERT11] proposes two, padding schemes:, ■, , ■, , Simple padding: Denoted by pad10*, appends a single bit 1 followed by the, minimum number of bits 0 such that the length of the result is a multiple of the, block length., Multirate padding: Denoted by pad10*1, appends a single bit 1 followed by, the minimum number of bits 0 followed by a single bit 1 such that the length, of the result is a multiple of the block length. This is the simplest padding, scheme that allows secure use of the same f with different rates r. FIPS 202, uses multirate padding., , After processing all of the blocks, the sponge function generates a sequence, of output blocks Z0, Z1, c , Zj - 1. The number of output blocks generated is, determined by the number of output bits desired. If the desired output is / bits, then, j blocks are produced, such that (j - 1) * r 6 / … j * r., Figure 11.15 shows the iterated structure of the sponge function. The sponge, construction operates on a state variable s of b = r + c bits, which is initialized, to all zeros and modified at each iteration. The value r is called the bitrate. This, value is the block size used to partition the input message. The term bitrate reflects the fact that r is the number of bits processed at each iteration: the larger the, value of r, the greater the rate at which message bits are processed by the sponge
Page 368 :
11.6 / SHA-3, b, , b, , r, , c, , r, , c, , 0, , 367, , r, , c, , 0, , r, , c, , r, , P0, , c, , Z0, , 0, , f, , f, s, P1, , 0c, , Z1, , f, s, P2, , 0c, , Pk–1, , 0c, , (b) Squeezing phase, , f, s, , (a) Absorbing phase, Figure 11.15, , Sponge Construction, , construction. The value c is referred to as the capacity. A discussion of the security implications of the capacity is beyond our scope. In essence, the capacity is a, measure of the achievable complexity of the sponge construction and therefore the, achievable level of security. A given implementation can trade claimed security for, speed by increasing the capacity c and decreasing the bitrate r accordingly, or vice, versa. The default values for Keccak are c = 1024 bits, r = 576 bits, and therefore, b = 1600 bits., The sponge construction consists of two phases. The absorbing phase proceeds, as follows: For each iteration, the input block to be processed is padded with zeroes, to extend its length from r bits to b bits. Then, the bitwise XOR of the extended
Page 369 :
368, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , message block and s is formed to create a b-bit input to the iteration function f. The, output of f is the value of s for the next iteration., If the desired output length / satisfies / … b, then at the completion of the, absorbing phase, the first / bits of s are returned and the sponge construction terminates. Otherwise, the sponge construction enters the squeezing phase. To begin, the, first / bits of s are retained as block Z0. Then, the value of s is updated with repeated, executions of f, and at each iteration, the first / bits of s are retained as block Zi, and concatenated with previously generated blocks. The process continues through, (j - 1) iterations until we have (j - 1) * r 6 / … j * r. At this point the first /, bits of the concatenated block Z are returned., Note that the absorbing phase has the structure of a typical hash function., A common case will be one in which the desired hash length is less than or equal, to the input block length; that is, / … r. In that case, the sponge construction terminates after the absorbing phase. If a longer output than b bits is required, then the, squeezing phase is employed. Thus the sponge construction is quite flexible. For, example, a short message with a length r could be used as a seed and the sponge, construction would function as a pseudorandom number generator., To summarize, the sponge construction is a simple iterated construction for, building a function F with variable-length input and arbitrary output length based, on a fixed-length transformation or permutation f operating on a fixed number b of, bits. The sponge construction is defined formally in [BERT11] as follows:, , Algorithm The sponge construction SPONGE[f, pad, r], Require: r < b, Interface: Z = sponge(M,/) with M ∈ Z2*, integer / > 0 and Z ∈ Z/2, P = M } pad[r](|M|), s = 0b, for i = 0 to |P|r − 1 do, s = s ⊕ (Pi } 0b − r), s = f(s), end for, Z =:s;r, while |Z|r r < / do, s = f (s), Z = Z } :s;r, end while, return : Z ; ℓ, , In the algorithm definition, the following notation is used: M is the length, in bits of a bit string M. A bit string M can be considered as a sequence of blocks, of some fixed length x, where the last block may be shorter. The number of, blocks of M is denoted by M x. The blocks of M are denoted by Mi and the index, ranges from 0 to M x - 1. The expression : M ; / denotes the truncation of M to, its first / bits.
Page 370 :
11.6 / SHA-3, Table 11.5, , 369, , SHA-3 Parameters, , Message Digest Size, , 224, , 256, , 384, , 512, , no maximum, , no maximum, , no maximum, , no maximum, , 1152, , 1088, , 832, , 576, , Word Size, , 64, , 64, , 64, , 64, , Number of Rounds, , 24, , 24, , 24, , 24, , Capacity c, , 448, , 512, , 768, , 1024, , 112, , 128, , 192, , Message Size, Block Size (bitrate r), , Collision Resistance, , 2, , 2, , 2, , 2256, , Second Preimage Resistance, , 2224, , 2256, , 2384, , 2512, , Note: All sizes and security levels—are measured in bits., , SHA-3 makes use of the iteration function f, labeled Keccak-f, which is, described in the next section. The overall SHA-3 function is a sponge function, expressed as Keccak[r, c] to reflect that SHA-3 has two operational parameters, r,, the message block size, and c, the capacity, with the default of r + c = 1600 bits., Table 11.5 shows the supported values of r and c. As Table 11.5 shows, the hash, function security associated with the sponge construction is a function of the, capacity c., In terms of the sponge algorithm defined above, Keccak[r, c] is defined as, Keccak [r, c]∆ SPONGE [Keccak@f [r + c], pad 10*1, r], We now turn to a discussion of the iteration function Keccak-f., , The SHA-3 Iteration Function f, We now examine the iteration function Keccak-f used to process each successive, block of the input message. Recall that f takes as input a 1600-bit variable s consisting of r bits, corresponding to the message block size followed by c bits, referred to, as the capacity. For internal processing within f, the input state variable s is organized as a 5 * 5 * 64 array a. The 64-bit units are referred to as lanes. For our, purposes, we generally use the notation a[x, y, z] to refer to an individual bit with, the state array. When we are more concerned with operations that affect entire, lanes, we designate the 5 * 5 matrix as L[x, y], where each entry in L is a 64-bit, lane. The use of indices within this matrix is shown in Figure 11.16.4 Thus, the columns are labeled x = 0 through x = 4, the rows are labeled y = 0 through y = 4,, and the individual bits within a lane are labeled z = 0 through z = 63. The mapping, between the bits of s and those of a is, s[64(5y + x) + z] = a[x, y, z], , 4, , Note that the first index (x) designates a column and the second index (y) designates a row. This is, in conflict with the convention used in most mathematics sources, where the first index designates a, row and the second index designates a column (e.g., Knuth, D. The Art of Computing Programming,, Volume 1, Fundamental Algorithms; and Korn, G., and Korn, T. Mathematical Handbook for Scientists, and Engineers).
Page 371 :
370, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, x=0, , x=1, , x=2, , x=3, , x=4, , y=4, , L[0, 4], , L[1, 4], , L[2, 4], , L[3, 4], , L[4, 4], , y=3, , L[0, 3], , L[1, 3], , L[2, 3], , L[3, 3], , L[4, 3], , y=2, , L[0, 2], , L[1, 2], , L[2, 2], , L[3, 2], , L[4, 2], , y=1, , L[0, 1], , L[1, 1], , L[2, 1], , L[4, 1], , L[4, 1], , y=0, , L[0, 0], , L[1, 0], , L[2, 0], , L[3, 0], , L[4, 0], , (a) State variable as 5, , a[x, y, 0] a[x, y, 1] a[x, y, 2], , 5 matrix A of 64-bit words, , a[x, y, z], , a[x, y, 62] a[x, y, 63], , (b) Bit labeling of 64-bit words, , Figure 11.16, , SHA-3 State Matrix, , We can visualize this with respect to the matrix in Figure 11.16. When treating the state as a matrix of lanes, the first lane in the lower left corner, L[0, 0], corresponds to the first 64 bits of s. The lane in the second column, lowest row, L[1,, 0], corresponds to the next 64 bits of s. Thus, the array a is filled with the bits of s, starting with row y = 0 and proceeding row by row., STRUCTURE OF f The function f is executed once for each input block of the message, to be hashed. The function takes as input the 1600-bit state variable and converts, it into a 5 * 5 matrix of 64-bit lanes. This matrix then passes through 24 rounds of, processing. Each round consists of five steps, and each step updates the state matrix, by permutation or substitution operations. As shown in Figure 11.17, the rounds are, identical with the exception of the final step in each round, which is modified by a, round constant that differs for each round., The application of the five steps can be expressed as the composition5 of, functions:, R = ioxoporou, Table 11.6 summarizes the operation of the five steps. The steps have a simple description leading to a specification that is compact and in which no trapdoor, can be hidden. The operations on lanes in the specification are limited to bitwise, Boolean operations (XOR, AND, NOT) and rotations. There is no need for table, lookups, arithmetic operations, or data-dependent rotations. Thus, SHA-3 is easily, and efficiently implemented in either hardware or software., We examine each of the step functions in turn., , If f and g are two functions, then the function F with the equation y = F(x) = g[f(x)] is called the, composition of f and g and is denoted as F = g o f., , 5, , Hiva-Network.Com
Page 372 :
11.6 / SHA-3, , 371, , s, theta (u) step, , Round 0, , rho (r) step, , rot(x, y), , pi (p) step, chi (x) step, iota (i) step, , RC[0], , theta (u) step, , Round 23, , rho (r) step, , rot(x, y), , pi (p) step, chi (x) step, iota (i) step, , RC[23], , s, , Figure 11.17, Table 11.6, , SHA-3 Iteration Function f, , Step Functions in SHA-3, , Function, , Type, , Description, , u, , Substitution, , New value of each bit in each word depends on its current, value and on one bit in each word of preceding column, and one bit of each word in succeeding column., , r, , Permutation, , The bits of each word are permuted using a circular bit, shift. W[0, 0] is not affected., , p, , Permutation, , Words are permuted in the 5 * 5 matrix. W[0, 0] is not, affected., , x, , Substitution, , New value of each bit in each word depends on its current, value and on one bit in next word in the same row and one, bit in the second next word in the same row., , i, , Substitution, , W[0, 0] is updated by XOR with a round constant., , THETA STEP FUNCTION The Keccak reference defines the u function as follows. For, bit z in column x, row y,, 4, , 4, , y =0, , y =0, , u: a[x, y, z] d a[x, y, z] ⊕ a a[(x - 1), y=, z] ⊕ a a[(x + 1), y=, (z - 1)], =, =, , (11.1)
Page 373 :
372, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , where the summations are XOR operations. We can see more clearly what this, operation accomplishes with reference to Figure 11.18a. First, define the bitwise, XOR of the lanes in column x as, C[x] = L[x, 0] ⊕ L[x, 1] ⊕ L[x, 2] ⊕ L[x, 3] ⊕ L[x, 4], Consider lane L[x, y] in column x, row y. The first summation in Equation 11.1, performs a bitwise XOR of the lanes in column (x - 1) mod 4 to form the 64-bit, lane C[x - 1]. The second summation performs a bitwise XOR of the lanes in, column (x + 1) mod 4, and then rotates the bits within the 64-bit lane so that the, bit in position z is mapped into position z + 1 mod 64. This forms the lane ROT, (C[x + 1], 1). These two lanes and L[x, y] are combined by bitwise XOR to form, the updated value of L[x, y]. This can be expressed as, L[x, y] d L[x, y] ⊕ C[x - 1] ⊕ ROT(C[x + 1], 1), Figure 11.18.a illustrates the operation on L[3, 2]. The same operation is, performed on all of the other lanes in the matrix., , x=0, , x=1, , x=2, , x=3, , x=4, , y=4, , L[0, 4], , L[1, 4], , L[2, 4], , L[3, 4], , L[4, 4], , y=3, , L[0, 3], , L[1, 3], , L[2, 3], , L[3, 3], , L[4, 3], , y=2, , L[0, 2], , L[1, 2], , L[2, 2], , L[3, 2], , L[4, 2], , y=1, , L[0, 1], , L[1, 1], , L[2, 1], , L[4, 1], , L[4, 1], , y=0, , L[0, 0], , L[1, 0], , L[2, 0], , L[3, 0], , L[4, 0], , C[1], , L[2, 3], , ROT(C[3], 1), , L[2, 3], , (a) u step function, x=0, , x=1, , x=2, , x=3, , x=4, , y=4, , L[0, 4], , L[1, 4], , L[2, 4], , L[3, 4], , L[4, 4], , y=3, , L[0, 3], , L[1, 3], , L[2, 3], , L[3, 3], , L[4, 3], , y=2, , L[0, 2], , L[1, 2], , L[2, 2], , L[3, 2], , L[4, 2], , y=1, , L[0, 1], , L[1, 1], , L[2, 1], , L[4, 1], , L[4, 1], , y=0, , L[0, 0], , L[1, 0], , L[2, 0], , L[3, 0], , L[4, 0], , L[2, 3], , L[3, 3], , L[2, 3], , (b) x step function, Figure 11.18 Theta and Chi Step Functions, , AND, , L[4, 3]
Page 374 :
11.6 / SHA-3, , 373, , Several observations are in order. Each bit in a lane is updated using the bit itself, and one bit in the same bit position from each lane in the preceding column and one, bit in the adjacent bit position from each lane in the succeeding column. Thus the updated value of each bit depends on 11 bits. This provides good mixing. Also, the theta, step provides good diffusion, as that term was defined in Chapter 4. The designers of, Keccak state that the theta step provides a high level of diffusion on average and that, without theta, the round function would not provide diffusion of any significance., RHO STEP FUNCTION The r function is defined as follows:, r: a[x, y, z] d a[x, y, z] if x = y = 0, otherwise,, r: a[x, y, z] d a Jx, y, az with t satisfying 0 … t 6 24 and ¢, , 0, 2, , (t + 1)(t + 2), bR, 2, , (11.2), , 1 t 1, x, ≤ ¢ ≤ = ¢ ≤ in GF(5)2 * 2, 3, 0, y, , It is not immediately obvious what this step performs, so let us look at the, process in detail., 1. The lane in position (x, y) = (0, 0), that is L[0, 0], is unaffected. For all other, words, a circular bit shift within the lane is performed., 2. The variable t, with 0 … t 6 24, is used to determine both the amount of the, circular bit shift and which lane is assigned which shift value., 3. The 24 individual bit shifts that are performed have the respective values, (t + 1)(t + 2), mod 64., 2, 4. The shift determined by the value of t is performed on the lane in position, (x, y) in the 5 * 5 matrix of lanes. Specifically, for each value of t, the correx, 0, sponding matrix position is defined by ¢ ≤ = ¢, y, 2, t = 3, we have, x, 0, ¢ ≤ = ¢, y, 2, , 1 t 1, ≤ ¢ ≤. For example, for, 3, 0, , 1 3 1, ≤ ¢ ≤ mod 5, 3, 0, , = ¢, , 0, 2, , 1 0, ≤¢, 3 2, , 1 0, ≤¢, 3 2, , = ¢, , 0, 2, , 1 0, ≤¢, 3 2, , 1 0, ≤ ¢ ≤ mod 5, 3 2, , = ¢, , 0, 2, , 1 2, 0, ≤ ¢ ≤ mod 5 = ¢, 3 6, 2, , 1, 1, = ¢ ≤ mod 5 = ¢ ≤, 7, 2, , 1 1, ≤ ¢ ≤ mod 5, 3 0, , 1 2, ≤ ¢ ≤ mod 5, 3 1
Page 375 :
374, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, Table 11.7, , Rotation Values Used in SHA-3, (a) Calculation of values and positions, , t, , g(t), , g (t) mod 64, , x, y, , t, , g(t), , g (t) mod 64, , x, y, , 0, , 1, , 1, , 1, 0, , 12, , 91, , 27, , 4, 0, , 1, , 3, , 3, , 0, 2, , 13, , 105, , 41, , 0, 3, , 2, , 6, , 6, , 2, 1, , 14, , 120, , 56, , 3, 4, , 3, , 10, , 10, , 1, 2, , 15, , 136, , 8, , 4, 3, , 4, , 15, , 15, , 2, 3, , 16, , 153, , 25, , 3, 2, , 5, , 21, , 21, , 3, 3, , 17, , 171, , 43, , 2, 2, , 6, , 28, , 28, , 3, 0, , 18, , 190, , 62, , 2, 0, , 7, , 36, , 36, , 0, 1, , 19, , 210, , 18, , 0, 4, , 8, , 45, , 45, , 1, 3, , 20, , 231, , 39, , 4, 2, , 9, , 55, , 55, , 3, 1, , 21, , 253, , 61, , 2, 4, , 10, , 66, , 2, , 1, 4, , 22, , 276, , 20, , 4, 1, , 11, , 78, , 14, , 4, 4, , 23, , 300, , 44, , 1, 1, , Note: g(t) = (t + 1)(t + 2)/2, x, 0, ¢ ≤ = ¢, y, 2, , 1 t 1, ≤ ¢ ≤ mod 5, 0, 3, , (b) Rotation values by word position in matrix, x = 0, , x = 1, , x = 2, , x = 3, , x = 4, , y = 4, , 18, , 2, , 61, , 56, , 14, , y = 3, , 41, , 45, , 15, , 21, , 8, , y = 2, , 3, , 10, , 43, , 25, , 39, , y = 1, , 36, , 44, , 6, , 55, , 20, , y = 0, , 0, , 1, , 62, , 28, , 27, , Table 11.7 shows the calculations that are performed to determine the amount, of the bit shift and the location of each bit shift value. Note that all of the rotation, amounts are different., The r function thus consists of a simple permutation (circular shift) within, each lane. The intent is to provide diffusion within each lane. Without this function,, diffusion between lanes would be very slow., PI STEP FUNCTION The p function is defined as follows:, x, 0, p: a[x, y] d a[x=, y=], with ¢ ≤ = ¢, y, 2, , 1 x=, ≤¢ ≤, 3 y=, , (11.3), , This can be rewritten as (x, y) * (y, (2x + 3y)). Thus, the lanes within the, 5 * 5 matrix are moved so that the new x position equals the old y position and the
Page 376 :
11.6 / SHA-3, x=0, , x=1, , x=2, , x=3, , x=4, , 2, row, , 4, row, , 1, row, , 3, row, , 375, , 0, row, 2, row, , y=4, , Z[0, 4], , Z[1, 4], , Z[2, 4], , Z[3, 4], , Z[4, 4], , y=3, , Z[0, 3], , Z[1, 3], , Z[2, 3], , Z[3, 3], , Z[4, 3], , y=2, , Z[0, 2], , Z[1, 2], , Z[2, 2], , Z[3, 2], , Z[4, 2], , 4, row, 1, row, , y=1, , Z[0, 1], , Z[1, 1], , Z[2, 1], , Z[3, 1], , Z[4, 1], , 3, row, , y=0, , Z[0, 0], , Z[1, 0], , Z[2, 0], , Z[3, 0], , Z[4, 0], , (a) Lane position at start of step, , x=0, , x=1, , x=2, , x=3, , x=4, , y=4, , Z[2, 0], , Z[3, 1], , Z[4, 2], , Z[0, 3], , Z[1, 4], , y=3, , Z[4, 0], , Z[0, 1], , Z[1, 2], , Z[2, 3], , Z[3, 4], , y=2, , Z[1, 0], , Z[2, 1], , Z[3, 2], , Z[4, 3], , Z[0, 4], , y=1, , Z[3, 0], , Z[4, 1], , Z[0, 2], , Z[1, 3], , Z[2, 4], , y=0, , Z[0, 0], , Z[1, 1], , Z[2, 2], , Z[3, 3], , Z[4, 4], , (b) Lane position after permutation, , Figure 11.19 Pi Step Function, , new y position is determined by (2x + 3y) mod 5. Figure 11.19 helps in visualizing, this permutation. Lanes that are along the same diagonal (increasing in y value,, going from left to right) prior to p are arranged on the same row in the matrix after, p is executed. Note that the position of L[0, 0] is unchanged., Thus the p step is a permutation of lanes: The lanes move position within the, 5 * 5 matrix. The r step is a permutation of bits: Bits within a lane are rotated., Note that the p step matrix positions are calculated in the same way that, for the r, step, the one-dimensional sequence of rotation constants is mapped to the lanes of, the matrix., CHI STEP FUNCTION The x function is defined as follows:, x: a[x] d a[x] ⊕ ((a[x + 1] ⊕ 1) AND a[x + 2]), , (11.4), , This function operates to update each bit based on its current value and the, value of the corresponding bit position in the next two lanes in the same row. The
Page 377 :
376, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , operation is more clearly seen if we consider a single bit a[x, y, z] and write out the, Boolean expression:, a[x, y, z] d a[x, y, z] ⊕ (NOT(a[x + 1, y, z])) AND (a[x + 2, y, z]), Figure 11.18b illustrates the operation of the x function on the bits of the, lane L[3, 2]. This is the only one of the step functions that is a nonlinear mapping., Without it, the SHA-3 round function would be linear., IOTA STEP FUNCTION The i function is defined as follows:, i: a d a ⊕ RC[ir], , (11.5), , This function combines an array element with a round constant that differs for, each round. It breaks up any symmetry induced by the other four step functions. In, fact, Equation 11.5 is somewhat misleading. The round constant is applied only to, the first lane of the internal state array. We express this is as follows:, L[0, 0] d L[0, 0] ⊕ RC[ir] 0 … ir … 24, Table 11.8 lists the 24 64-bit round constants. Note that the Hamming weight,, or number of 1 bits, in the round constants ranges from 1 to 6. Most of the bit positions are zero and thus do not change the corresponding bits in L[0, 0]. If we take, the cumulative OR of all 24 round constants, we get, RC[0] OR RC[1] OR c OR RC[23] = 800000008000808B, Thus, only 7 bit positions are active and can affect the value of L[0, 0]., Of course, from round to round, the permutations and substitutions propagate the, effects of the i function to all of the lanes and all of the bit positions in the matrix., It is easily seen that the disruption diffuses through u and x to all lanes of the state, after a single round., Table 11.8, , Round Constants in SHA-3, , Round, , Constant, (hexadecimal), , Number, of 1 bits, , Round, , Constant, (hexadecimal), , Number, of 1 bits, , 0, , 0000000000000001, , 1, , 12, , 000000008000808B, , 6, , 1, , 0000000000008082, , 3, , 13, , 800000000000008B, , 5, , 2, , 800000000000808A, , 5, , 14, , 8000000000008089, , 5, , 3, , 8000000080008000, , 3, , 15, , 8000000000008003, , 4, , 4, , 000000000000808B, , 5, , 16, , 8000000000008002, , 3, , 5, , 0000000080000001, , 2, , 17, , 8000000000000080, , 2, , 6, , 8000000080008081, , 5, , 18, , 000000000000800A, , 3, , 7, , 8000000000008009, , 4, , 19, , 800000008000000A, , 4, , 8, , 000000000000008A, , 3, , 20, , 8000000080008081, , 5, , 9, , 0000000000000088, , 2, , 21, , 8000000000008080, , 3, , 10, , 0000000080008009, , 4, , 22, , 0000000080000001, , 2, , 11, , 000000008000000A, , 3, , 23, , 8000000080008008, , 4
Page 378 :
11.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 377, , 11.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, absorbing phase, big endian, birthday attack, birthday paradox, bitrate, capacity, Chi step function collision, resistant, compression function, cryptographic hash function, hash code, hash function, hash value, , Iota step function, Keccak, keyed hash function, lane, little endian, MD4, MD5, message authentication code, (MAC), message digest, one-way hash function, Pi step function, preimage resistant, , Rho step function, second preimage resistant, SHA-1, SHA-224, SHA-256, SHA-3, SHA-384, SHA-512, sponge construction, squeezing phase, strong collision resistance, Theta step function, weak collision resistance, , Review Questions, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7, 11.8, 11.9, , What characteristics are needed in a secure hash function?, What is the difference between weak and strong collision resistance?, What is the role of a compression function in a hash function?, What is the difference between little-endian and big-endian format?, What basic arithmetical and logical functions are used in SHA?, Describe the set of criteria used by NIST to evaluate SHA-3 candidates., Define the term sponge construction., Briefly describe the internal structure of the iteration function f., List and briefly describe the step functions that comprise the iteration function f., , Problems, 11.1, , 11.2, , The high-speed transport protocol XTP (Xpress Transfer Protocol) uses a 32-bit, checksum function defined as the concatenation of two 16-bit functions: XOR and, RXOR, defined in Section 11.4 as “two simple hash functions” and illustrated in, Figure 11.5., a. Will this checksum detect all errors caused by an odd number of error bits?, Explain., b. Will this checksum detect all errors caused by an even number of error bits? If not,, characterize the error patterns that will cause the checksum to fail., c. Comment on the effectiveness of this function for use as a hash function for, authentication., a. Consider the Davies and Price hash code scheme described in Section 11.4 and, assume that DES is used as the encryption algorithm:, Hi = Hi - 1 ⊕ E(Mi, H i - 1)
Page 379 :
378, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, Recall the complementarity property of DES (Problem 3.14): If Y = E(K, X),, then Y′ = E(K′, X′). Use this property to show how a message consisting of, blocks M1, M2, c , MN can be altered without altering its hash code., b. Show that a similar attack will succeed against the scheme proposed in [MEYE88]:, Hi = Mi ⊕ E(Hi - 1, Mi), 11.3, , a. Consider the following hash function. Messages are in the form of a sequence of, t, , numbers in Z n, M = (a1, a2, c at). The hash value h is calculated as ¢ a ai ≤ for, i=1, , some predefined value n. Does this hash function satisfy any of the requirements, for a hash function listed in Table 11.1? Explain your answer., t, , b. Repeat part (a) for the hash function h = ¢ a (ai)2 ≤ mod n., i=1, , 11.4, , 11.5, , c. Calculate the hash function of part (b) for M = (189, 632, 900, 722, 349) and, n = 989., It is possible to use a hash function to construct a block cipher with a structure similar, to DES. Because a hash function is one way and a block cipher must be reversible (to, decrypt), how is it possible?, Now consider the opposite problem: using an encryption algorithm to construct, a one-way hash function. Consider using RSA with a known key. Then process a, message consisting of a sequence of blocks as follows: Encrypt the first block, XOR, the result with the second block and encrypt again, etc. Show that this scheme is not, secure by solving the following problem. Given a two-block message B1, B2, and, its hash, RSAH(B 1,B 2) = RSA(RSA(B1) ⊕ B2), , 11.6, , 11.7, , 11.8, 11.9, , 11.10, , 11.11, , Given an arbitrary block C1, choose C2 so that RSAH(C1, C2) = RSAH(B1, B2)., Thus, the hash function does not satisfy weak collision resistance., Suppose H(m) is a collision-resistant hash function that maps a message of arbitrary, bit length into an n-bit hash value. Is it true that, for all messages x, x′ with x ≠ x′,, we have H(x) ≠ H(x′) Explain your answer., In Figure 11.12, it is assumed that an array of 80 64-bit words is available to store the, values of Wt, so that they can be precomputed at the beginning of the processing of, a block. Now assume that space is at a premium. As an alternative, consider the use, of a 16-word circular buffer that is initially loaded with W0 through W15. Design an, algorithm that, for each step t, computes the required input value Wt., For SHA-512, show the equations for the values of W16, W18, W23, and W31., State the value of the padding field in SHA-512 if the length of the message is, a. 2942 bits, b. 2943 bits, c. 2944 bits, State the value of the length field in SHA-512 if the length of the message is, a. 2942 bits, b. 2943 bits, c. 2944 bits, Suppose a 1a 2a 3a 4 are the 4 bytes in a 32-bit word. Each a i can be viewed as an integer, in the range 0 to 255, represented in binary. In a big-endian architecture, this word, represents the integer, a 1224 + a 2216 + a 328 + a 4
Page 380 :
11.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 379, , In a little-endian architecture, this word represents the integer, a 4224 + a 3216 + a 228 + a 1, a. Some hash functions, such as MD5, assume a little-endian architecture. It is important that the message digest be independent of the underlying architecture. Therefore, to perform the modulo 2 addition operation of MD5 or RIPEMD-160 on, a big-endian architecture, an adjustment must be made. Suppose X = x 1 x 2 x 3 x 4, and Y = y1 y2 y3 y4. Show how the MD5 addition operation (X + Y) would be, carried out on a big-endian machine., b. SHA assumes a big-endian architecture. Show how the operation (X + Y) for, SHA would be carried out on a little-endian machine., 11.12 This problem introduces a hash function similar in spirit to SHA that operates on, letters instead of binary data. It is called the toy tetragraph hash (tth).6 Given a message consisting of a sequence of letters, tth produces a hash value consisting of four, letters. First, tth divides the message into blocks of 16 letters, ignoring spaces, punctuation, and capitalization. If the message length is not divisible by 16, it is padded, out with nulls. A four-number running total is maintained that starts out with the, value (0, 0, 0, 0); this is input to the compression function for processing the first, block. The compression function consists of two rounds., Round 1 Get the next block of text and arrange it as a row-wise 4 * 4 block of text, and convert it to numbers (A = 0, B = 1, etc.). For example, for the block, ABCDEFGHIJKLMNOP, we have, A, , B, , C, , D, , 0, , 1, , 2, , 3, , E, , F, , G, , H, , 4, , 5, , 6, , 7, , I, , J, , K, , L, , 8, , 9, , 10, , 11, , M, , N, , O, , P, , 12, , 13, , 14, , 15, , Then, add each column mod 26 and add the result to the running total, mod 26. In this, example, the running total is (24, 2, 6, 10)., Round 2 Using the matrix from round 1, rotate the first row left by 1, second row left by 2,, third row left by 3, and reverse the order of the fourth row., In our example:, B, , C, , D, , A, , 1, , 2, , 3, , G, , H, , E, , L, , I, , J, , P, , O, , N, , M, , 0, , F, , 6, , 7, , 4, , 5, , K, , 11, , 8, , 9, , 10, , 15, , 14, , 13, , 12, , Now, add each column mod 26 and add the result to the running total. The new running total is (5, 7, 9, 11). This running total is now the input into the first round of the, compression function for the next block of text. After the final block is processed,, convert the final running total to letters. For example, if the message is ABCDEFGHIJKLMNOP, then the hash is FHJL., , 6, , I thank William K. Mason, of the magazine staff of The Cryptogram, for providing this example., , Hiva-Network.Com
Page 381 :
380, , CHAPTER 11 / CRYPTOGRAPHIC HASH FUNCTIONS, , a. Draw figures comparable to Figures 11.9 and 11.10 to depict the overall tth logic, and the compression function logic., , b. Calculate the hash function for the 22-letter message “Practice makes us perfect.”, c. To demonstrate the weakness of tth, find a message of length 32-letter to produces, 11.13, 11.14, , 11.15, , 11.16, , the same hash., For each of the possible capacity values of SHA-3 (Table 11.5), which lanes in the, internal 55 state matrix start out as lanes of all zeros?, Consider the SHA-3 option with a block size of 1024 bits and assume that each of the, lanes in the first message block (P0) has at least one nonzero bit. To start, all of the, lanes in the internal state matrix that correspond to the capacity portion of the initial, state are all zeros. Show how long it will take before all of these lanes have at least, one nonzero bit. Note: Ignore the permutation. That is, keep track of the original zero, lanes even after they have changed position in the matrix., Consider the state matrix as illustrated in Figure 11.16a. Now rearrange the rows and, columns of the matrix so that L[0, 0] is in the center. Specifically, arrange the columns, in the left-to-right order (x = 3, x = 4, x = 0, x = 1, x = 2) and arrange the rows in, the top-to-bottom order (y = 2, y = 1, y = 0, y = 4, y = 6). This should give you, some insight into the permutation algorithm used for the function and for permuting the rotation constants in the function. Using this rearranged matrix, describe the, permutation algorithm., The function only affects L[0, 0]. Section 11.6 states that the changes to L[0, 0] diffuse, through u and to all lanes of the state after a single round., a. Show that this is so., b. How long before all of the bit positions in the matrix are affected by the changes, to L[0, 0]?
Page 382 :
CHAPTER, , Message Authentication, Codes, 12.1, , Message Authentication Requirements, , 12.2, , Message Authentication Functions, Message Encryption, Message Authentication Code, , 12.3, , Requirements for Message Authentication Codes, , 12.4, , Security of MACs, Brute-Force Attacks, Cryptanalysis, , 12.5, , MACs Based on Hash Functions: HMAC, HMAC Design Objectives, HMAC Algorithm, Security of HMAC, , 12.6, , MACs Based on Block Ciphers: DAA and CMAC, Data Authentication Algorithm, Cipher-Based Message Authentication Code (CMAC), , 12.7, , Authenticated Encryption: CCM and GCM, Counter with Cipher Block Chaining-Message Authentication Code, Galois/Counter Mode, , 12.8, , Key Wrapping, Background, The Key Wrapping Algorithm, Key Unwrapping, , 12.9, , Pseudorandom Number Generation Using Hash Functions and MACs, PRNG Based on Hash Function, PRNG Based on MAC Function, , 12.10 Key Terms, Review Questions, and Problems, , 381
Page 383 :
382, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ List and explain the possible attacks that are relevant to message, authentication., ◆ Define the term message authentication code., ◆ List and explain the requirements for a message authentication code., ◆ Present an overview of HMAC., ◆ Present an overview of CMAC., ◆ Explain the concept of authenticated encryption., ◆ Present an overview of CCM., ◆ Present an overview of GCM., ◆ Discuss the concept of key wrapping and explain its use., ◆ Understand how a hash function or a message authentication code can be, used for pseudorandom number generation., , One of the most fascinating and complex areas of cryptography is that of message, authentication and the related area of digital signatures. It would be impossible, in, anything less than book length, to exhaust all the cryptographic functions and protocols that have been proposed or implemented for message authentication and digital, signatures. Instead, the purpose of this chapter and the next is to provide a broad, overview of the subject and to develop a systematic means of describing the various, approaches., This chapter begins with an introduction to the requirements for authentication and digital signature and the types of attacks to be countered. Then the, basic approaches are surveyed. The remainder of the chapter deals with the fundamental approach to message authentication known as the message authentication, code (MAC). Following an overview of this topic, the chapter looks at security, considerations for MACs. This is followed by a discussion of specific MACs in, two categories: those built from cryptographic hash functions and those built using, a block cipher mode of operation. Next, we look at a relatively recent approach, known as authenticated encryption. Finally, we look at the use of cryptographic, hash functions and MACs for pseudorandom number generation., , 12.1 MESSAGE AUTHENTICATION REQUIREMENTS, In the context of communications across a network, the following attacks can be, identified., 1. Disclosure: Release of message contents to any person or process not possessing the appropriate cryptographic key.
Page 384 :
12.2 / MESSAGE AUTHENTICATION FUNCTIONS, , 383, , 2. Traffic analysis: Discovery of the pattern of traffic between parties. In a, connection-oriented application, the frequency and duration of connections could be determined. In either a connection-oriented or connectionless, environment, the number and length of messages between parties could be, determined., 3. Masquerade: Insertion of messages into the network from a fraudulent source., This includes the creation of messages by an opponent that are purported to, come from an authorized entity. Also included are fraudulent acknowledgments of message receipt or nonreceipt by someone other than the message, recipient., 4. Content modification: Changes to the contents of a message, including insertion, deletion, transposition, and modification., 5. Sequence modification: Any modification to a sequence of messages between, parties, including insertion, deletion, and reordering., 6. Timing modification: Delay or replay of messages. In a connection-oriented, application, an entire session or sequence of messages could be a replay of, some previous valid session, or individual messages in the sequence could be, delayed or replayed. In a connectionless application, an individual message, (e.g., datagram) could be delayed or replayed., 7. Source repudiation: Denial of transmission of message by source., 8. Destination repudiation: Denial of receipt of message by destination., Measures to deal with the first two attacks are in the realm of message, confidentiality and are dealt with in Part One. Measures to deal with items, (3) through (6) in the foregoing list are generally regarded as message authentication. Mechanisms for dealing specifically with item (7) come under the heading of, digital signatures. Generally, a digital signature technique will also counter some, or all of the attacks listed under items (3) through (6). Dealing with item (8) may, require a combination of the use of digital signatures and a protocol designed to, counter this attack., In summary, message authentication is a procedure to verify that received, messages come from the alleged source and have not been altered. Message authentication may also verify sequencing and timeliness. A digital signature is an, authentication technique that also includes measures to counter repudiation by the, source., , 12.2 MESSAGE AUTHENTICATION FUNCTIONS, Any message authentication or digital signature mechanism has two levels of functionality. At the lower level, there must be some sort of function that produces an, authenticator: a value to be used to authenticate a message. This lower-level function is then used as a primitive in a higher-level authentication protocol that enables, a receiver to verify the authenticity of a message., This section is concerned with the types of functions that may be used to produce an authenticator. These may be grouped into three classes.
Page 385 :
384, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, ■, ■, ■, , Hash function: A function that maps a message of any length into a fixed-length, hash value, which serves as the authenticator, Message encryption: The ciphertext of the entire message serves as its, authenticator, Message authentication code (MAC): A function of the message and a secret, key that produces a fixed-length value that serves as the authenticator, , Hash functions, and how they may serve for message authentication, are discussed in Chapter 11. The remainder of this section briefly examines the remaining, two topics. The remainder of the chapter elaborates on the topic of MACs., , Message Encryption, Message encryption by itself can provide a measure of authentication. The analysis, differs for symmetric and public-key encryption schemes., SYMMETRIC ENCRYPTION Consider the straightforward use of symmetric encryption, (Figure 12.1a). A message M transmitted from source A to destination B is encrypted, using a secret key K shared by A and B. If no other party knows the key, then confidentiality is provided: No other party can recover the plaintext of the message., Source A, M, , Destination B, , E, , M, , D, E(K, M), , K, , K, , (a) Symmetric encryption: confidentiality and authentication, , M, , E, , M, , D, E(PUb, M), , PUb, , PRb, , (b) Public-key encryption: confidentiality, , M, , E, , M, , D, E(PRa, M), , PRa, , PUa, , (c) Public-key encryption: authentication and signature, , M, , E, , E, , D, , D, , M, , PRa E(PRa, M) PUb E(PUb, E(PRa, M)) PRb E(PRa, M) PUa, , (d) Public-key encryption: confidentiality, authentication, and signature, Figure 12.1, , Basic Uses of Message Encryption
Page 386 :
12.2 / MESSAGE AUTHENTICATION FUNCTIONS, , 385, , In addition, B is assured that the message was generated by A. Why? The, message must have come from A, because A is the only other party that possesses, K and therefore the only other party with the information necessary to construct, ciphertext that can be decrypted with K. Furthermore, if M is recovered, B knows, that none of the bits of M have been altered, because an opponent that does not, know K would not know how to alter bits in the ciphertext to produce the desired, changes in the plaintext., So we may say that symmetric encryption provides authentication as well as, confidentiality. However, this flat statement needs to be qualified. Consider exactly, what is happening at B. Given a decryption function D and a secret key K, the, destination will accept any input X and produce output Y = D(K, X). If X is the, ciphertext of a legitimate message M produced by the corresponding encryption, function, then Y is some plaintext message M. Otherwise, Y will likely be a meaningless sequence of bits. There may need to be some automated means of determining at B whether Y is legitimate plaintext and therefore must have come from A., The implications of the line of reasoning in the preceding paragraph are profound from the point of view of authentication. Suppose the message M can be any, arbitrary bit pattern. In that case, there is no way to determine automatically, at the, destination, whether an incoming message is the ciphertext of a legitimate message., This conclusion is incontrovertible: If M can be any bit pattern, then regardless of, the value of X, the value Y = D(K, X) is some bit pattern and therefore must be, accepted as authentic plaintext., Thus, in general, we require that only a small subset of all possible bit patterns, be considered legitimate plaintext. In that case, any spurious ciphertext is unlikely, to produce legitimate plaintext. For example, suppose that only one bit pattern in, 106 is legitimate plaintext. Then the probability that any randomly chosen bit pattern, treated as ciphertext, will produce a legitimate plaintext message is only 10-6., For a number of applications and encryption schemes, the desired conditions, prevail as a matter of course. For example, suppose that we are transmitting Englishlanguage messages using a Caesar cipher with a shift of one (K = 1). A sends the, following legitimate ciphertext:, nbsftfbupbutboeepftfbupbutboemjuumfmbnctfbujwz, B decrypts to produce the following plaintext:, mareseatoatsanddoeseatoatsandlittlelambseativy, A simple frequency analysis confirms that this message has the profile of ordinary, English. On the other hand, if an opponent generates the following random sequence of letters:, zuvrsoevgqxlzwigamdvnmhpmccxiuureosfbcebtqxsxq, this decrypts to, ytuqrndufpwkyvhfzlcumlgolbbwhttqdnreabdaspwrwp, which does not fit the profile of ordinary English.
Page 387 :
386, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , It may be difficult to determine automatically if incoming ciphertext decrypts to intelligible plaintext. If the plaintext is, say, a binary object file or digitized X-rays, determination of properly formed and therefore authentic plaintext, may be difficult. Thus, an opponent could achieve a certain level of disruption, simply by issuing messages with random content purporting to come from a, legitimate user., One solution to this problem is to force the plaintext to have some structure, that is easily recognized but that cannot be replicated without recourse to the encryption function. We could, for example, append an error-detecting code, also, known as a frame check sequence (FCS) or checksum, to each message before encryption, as illustrated in Figure 12.2a. A prepares a plaintext message M and then, provides this as input to a function F that produces an FCS. The FCS is appended to, M and the entire block is then encrypted. At the destination, B decrypts the incoming block and treats the results as a message with an appended FCS. B applies the, same function F to attempt to reproduce the FCS. If the calculated FCS is equal to, the incoming FCS, then the message is considered authentic. It is unlikely that any, random sequence of bits would exhibit the desired relationship., Note that the order in which the FCS and encryption functions are performed, is critical. The sequence illustrated in Figure 12.2a is referred to in [DIFF79] as, internal error control, which the authors contrast with external error control, (Figure 12.2b). With internal error control, authentication is provided because an, opponent would have difficulty generating ciphertext that, when decrypted, would, have valid error control bits. If instead the FCS is the outer code, an opponent can, construct messages with valid error-control codes. Although the opponent cannot, know what the decrypted plaintext will be, he or she can still hope to create confusion and disrupt operations., , Source A, ||, , M, , Destination B, M, , E, , D, , F(M), , F, , M, , Compare, , F(M), , K, , E(K, [M || F(M)]), , K, , F, , (a) Internal error control, , M, , K, , E(K, M), , K, , D, , ||, , E, , F, E(K, M), , Compare, F, , F(E(K, M)), , (b) External error control, Figure 12.2, , Internal and External Error Control, , M
Page 388 :
12.2 / MESSAGE AUTHENTICATION FUNCTIONS, Bit: 0, , 4, , 10, , 16, , 20 octets, , Source port, , 387, , 31, Destination port, , Sequence number, Acknowledgment number, Data, offset, , Reserved, , Flags, , Checksum, , Window, Urgent pointer, , Options + padding, , Application data, , Figure 12.3 TCP Segment, , An error-control code is just one example; in fact, any sort of structuring, added to the transmitted message serves to strengthen the authentication capability., Such structure is provided by the use of a communications architecture consisting, of layered protocols. As an example, consider the structure of messages transmitted using the TCP/IP protocol architecture. Figure 12.3 shows the format of a TCP, segment, illustrating the TCP header. Now suppose that each pair of hosts shared, a unique secret key, so that all exchanges between a pair of hosts used the same, key, regardless of application. Then we could simply encrypt all of the datagram except the IP header. Again, if an opponent substituted some arbitrary bit pattern for, the encrypted TCP segment, the resulting plaintext would not include a meaningful header. In this case, the header includes not only a checksum (which covers the, header) but also other useful information, such as the sequence number. Because, successive TCP segments on a given connection are numbered sequentially, encryption assures that an opponent does not delay, misorder, or delete any segments., P UBLIC -K EY E NCRYPTION The straightforward use of public-key encryption, (Figure 12.1b) provides confidentiality but not authentication. The source (A) uses, the public key PUb of the destination (B) to encrypt M. Because only B has the corresponding private key PRb, only B can decrypt the message. This scheme provides, no authentication, because any opponent could also use B’s public key to encrypt a, message and claim to be A., To provide authentication, A uses its private key to encrypt the message, and, B uses A’s public key to decrypt (Figure 12.1c). This provides authentication using, the same type of reasoning as in the symmetric encryption case: The message must, have come from A because A is the only party that possesses PRa and therefore, the only party with the information necessary to construct ciphertext that can be, decrypted with PUa. Again, the same reasoning as before applies: There must be, some internal structure to the plaintext so that the receiver can distinguish between, well-formed plaintext and random bits.
Page 389 :
388, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , Assuming there is such structure, then the scheme of Figure 12.1c does provide authentication. It also provides what is known as digital signature.1 Only A, could have constructed the ciphertext because only A possesses PRa. Not even B,, the recipient, could have constructed the ciphertext. Therefore, if B is in possession, of the ciphertext, B has the means to prove that the message must have come from, A. In effect, A has “signed” the message by using its private key to encrypt. Note, that this scheme does not provide confidentiality. Anyone in possession of A’s public key can decrypt the ciphertext., To provide both confidentiality and authentication, A can encrypt M first, using its private key, which provides the digital signature, and then using B’s public key, which provides confidentiality (Figure 12.1d). The disadvantage of this approach is that the public-key algorithm, which is complex, must be exercised four, times rather than two in each communication., , Message Authentication Code, An alternative authentication technique involves the use of a secret key to generate, a small fixed-size block of data, known as a cryptographic checksum or MAC, that is, appended to the message. This technique assumes that two communicating parties,, say A and B, share a common secret key K. When A has a message to send to B, it, calculates the MAC as a function of the message and the key:, MAC = C(K, M), where, M, C, K, MAC, , =, =, =, =, , input message, MAC function, shared secret key, message authentication code, , The message plus MAC are transmitted to the intended recipient. The recipient, performs the same calculation on the received message, using the same secret key,, to generate a new MAC. The received MAC is compared to the calculated MAC, (Figure 12.4a). If we assume that only the receiver and the sender know the identity, of the secret key, and if the received MAC matches the calculated MAC, then, 1. The receiver is assured that the message has not been altered. If an attacker alters the message but does not alter the MAC, then the receiver’s calculation of, the MAC will differ from the received MAC. Because the attacker is assumed, not to know the secret key, the attacker cannot alter the MAC to correspond, to the alterations in the message., 2. The receiver is assured that the message is from the alleged sender. Because, no one else knows the secret key, no one else could prepare a message with a, proper MAC., , 1, , This is not the way in which digital signatures are constructed, as we shall see, but the principle is the, same., , Hiva-Network.Com
Page 390 :
12.2 / MESSAGE AUTHENTICATION FUNCTIONS, , Source A, , Destination B, ||, , M, , 389, , C, , M, , K, , K, , C, , Compare, , C(K, M), , (a) Message authentication, ||, , M, , E, , M, , D, , K1, K2, , E(K2, [M || C(K1, M)]), , C, , C, K1, , K2, , Compare, , C(K1, M), , (b) Message authentication and confidentiality; authentication tied to plaintext, E(K2, M), M, , E, , D, , ||, , K2, , C, , K1, , Compare, , M, , K2, , K1, C, , C(K1, E(K2, M)), , (c) Message authentication and confidentiality; authentication tied to ciphertext, Figure 12.4, , Basic Uses of Message Authentication code (MAC), , 3. If the message includes a sequence number (such as is used with HDLC, X.25,, and TCP), then the receiver can be assured of the proper sequence because an, attacker cannot successfully alter the sequence number., A MAC function is similar to encryption. One difference is that the MAC, algorithm need not be reversible, as it must be for decryption. In general, the MAC, function is a many-to-one function. The domain of the function consists of messages, of some arbitrary length, whereas the range consists of all possible MACs and all, possible keys. If an n-bit MAC is used, then there are 2n possible MACs, whereas, there are N possible messages with N W 2n. Furthermore, with a k-bit key, there, are 2k possible keys., For example, suppose that we are using 100-bit messages and a 10-bit MAC., Then, there are a total of 2100 different messages but only 210 different MACs. So,, on average, each MAC value is generated by a total of 2100/210 = 290 different messages. If a 5-bit key is used, then there are 25 = 32 different mappings from the set, of messages to the set of MAC values., It turns out that, because of the mathematical properties of the authentication, function, it is less vulnerable to being broken than encryption., The process depicted in Figure 12.4a provides authentication but not confidentiality, because the message as a whole is transmitted in the clear. Confidentiality, can be provided by performing message encryption either after (Figure 12.4b) or, before (Figure 12.4c) the MAC algorithm. In both these cases, two separate keys are
Page 391 :
390, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , needed, each of which is shared by the sender and the receiver. In the first case, the, MAC is calculated with the message as input and is then concatenated to the message. The entire block is then encrypted. In the second case, the message is encrypted, first. Then the MAC is calculated using the resulting ciphertext and is concatenated, to the ciphertext to form the transmitted block. Typically, it is preferable to tie the, authentication directly to the plaintext, so the method of Figure 12.4b is used., Because symmetric encryption will provide authentication and because it is, widely used with readily available products, why not simply use this instead of a, separate message authentication code? [DAVI89] suggests three situations in which, a message authentication code is used., 1. There are a number of applications in which the same message is broadcast to, a number of destinations. Examples are notification to users that the network, is now unavailable or an alarm signal in a military control center. It is cheaper, and more reliable to have only one destination responsible for monitoring authenticity. Thus, the message must be broadcast in plaintext with an associated, message authentication code. The responsible system has the secret key and, performs authentication. If a violation occurs, the other destination systems, are alerted by a general alarm., 2. Another possible scenario is an exchange in which one side has a heavy load, and cannot afford the time to decrypt all incoming messages. Authentication is, carried out on a selective basis, messages being chosen at random for checking., 3. Authentication of a computer program in plaintext is an attractive service. The, computer program can be executed without having to decrypt it every time,, which would be wasteful of processor resources. However, if a message authentication code were attached to the program, it could be checked whenever, assurance was required of the integrity of the program., Three other rationales may be added., 4. For some applications, it may not be of concern to keep messages secret, but, it is important to authenticate messages. An example is the Simple Network, Management Protocol Version 3 (SNMPv3), which separates the functions of, confidentiality and authentication. For this application, it is usually important, for a managed system to authenticate incoming SNMP messages, particularly, if the message contains a command to change parameters at the managed system. On the other hand, it may not be necessary to conceal the SNMP traffic., 5. Separation of authentication and confidentiality functions affords architectural flexibility. For example, it may be desired to perform authentication at, the application level but to provide confidentiality at a lower level, such as the, transport layer., 6. A user may wish to prolong the period of protection beyond the time of reception and yet allow processing of message contents. With message encryption, the, protection is lost when the message is decrypted, so the message is protected, against fraudulent modifications only in transit but not within the target system., Finally, note that the MAC does not provide a digital signature, because both, sender and receiver share the same key.
Page 392 :
12.3 / REQUIREMENTS FOR MESSAGE AUTHENTICATION CODES, , 391, , 12.3 REQUIREMENTS FOR MESSAGE AUTHENTICATION CODES, A MAC, also known as a cryptographic checksum, is generated by a function C of, the form, T = MAC(K, M), where M is a variable-length message, K is a secret key shared only by sender and receiver, and MAC(K, M) is the fixed-length authenticator, sometimes called a tag. The, tag is appended to the message at the source at a time when the message is assumed or, known to be correct. The receiver authenticates that message by recomputing the tag., When an entire message is encrypted for confidentiality, using either symmetric or asymmetric encryption, the security of the scheme generally depends on the, bit length of the key. Barring some weakness in the algorithm, the opponent must, resort to a brute-force attack using all possible keys. On average, such an attack will, require 2(k - 1) attempts for a k-bit key. In particular, for a ciphertext-only attack, the, opponent, given ciphertext C, performs Pi = D(Ki, C) for all possible key values Ki, until a Pi is produced that matches the form of acceptable plaintext., In the case of a MAC, the considerations are entirely different. In general,, the MAC function is a many-to-one function, due to the many-to-one nature of, the function. Using brute-force methods, how would an opponent attempt to discover a key? If confidentiality is not employed, the opponent has access to plaintext messages and their associated MACs. Suppose k 7 n; that is, suppose that, the key size is greater than the MAC size. Then, given a known M1 and T1, with, T1 = MAC(K, M1), the cryptanalyst can perform Ti = MAC(Ki, M1) for all possible key values ki. At least one key is guaranteed to produce a match of Ti = T1., Note that a total of 2k tags will be produced, but there are only 2n 6 2k different tag, values. Thus, a number of keys will produce the correct tag and the opponent has no, way of knowing which is the correct key. On average, a total of 2k/2n = 2(k - n) keys, will produce a match. Thus, the opponent must iterate the attack., ■, , Round 1, Given: M1, T1 = MAC(K, M1), Compute Ti = MAC(Ki, M1) for all 2k keys, Number of matches L 2(k - n), , ■, , Round 2, Given: M2, T2 = MAC(K, M2), Compute Ti = MAC(Ki, M2) for the 2(k - n) keys resulting from Round 1, Number of matches L 2(k - 2 * n), , And so on. On average, a rounds will be needed k = a * n. For example, if an, 80-bit key is used and the tag is 32 bits, then the first round will produce about 248, possible keys. The second round will narrow the possible keys to about 216 possibilities. The third round should produce only a single key, which must be the one used, by the sender.
Page 393 :
392, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , If the key length is less than or equal to the tag length, then it is likely that a, first round will produce a single match. It is possible that more than one key will, produce such a match, in which case the opponent would need to perform the same, test on a new (message, tag) pair., Thus, a brute-force attempt to discover the authentication key is no less effort and may be more effort than that required to discover a decryption key of the, same length. However, other attacks that do not require the discovery of the key, are possible., Consider the following MAC algorithm. Let M = (X1 } X2 } c } Xm) be a, message that is treated as a concatenation of 64-bit blocks Xi. Then define, ∆(M) = X1 ⊕ X2 ⊕ c ⊕ Xm, MAC(K, M) = E(K, ∆(M)), where ⊕ is the exclusive-OR (XOR) operation and the encryption algorithm, is DES in electronic codebook mode. Thus, the key length is 56 bits, and the tag, length is 64 bits. If an opponent observes {M } MAC(K, M)}, a brute-force attempt, to determine K will require at least 256 encryptions. But the opponent can attack the, system by replacing X1 through Xm - 1 with any desired values Y1 through Ym - 1 and, replacing Xm with Ym, where Ym is calculated as, Ym = Y1 ⊕ Y2 ⊕ g ⊕ Ym - 1 ⊕ ∆(M), The opponent can now concatenate the new message, which consists of Y1, through Ym, using the original tag to form a message that will be accepted as authentic by the receiver. With this tactic, any message of length 64 * (m - 1) bits can be, fraudulently inserted., Thus, in assessing the security of a MAC function, we need to consider the, types of attacks that may be mounted against it. With that in mind, let us state the, requirements for the function. Assume that an opponent knows the MAC function but does not know K. Then the MAC function should satisfy the following, requirements., 1. If an opponent observes M and MAC(K, M), it should be computationally, infeasible for the opponent to construct a message M′ such that, MAC(K, M′) = MAC(K, M), 2. MAC(K, M) should be uniformly distributed in the sense that for randomly, chosen messages, M and M′, the probability that MAC(K, M) = MAC(K, M′), is 2-n, where n is the number of bits in the tag., 3. Let M′ be equal to some known transformation on M. That is, M′ = f(M). For, example, f may involve inverting one or more specific bits. In that case,, Pr [MAC(K, M) = MAC(K, M′)] = 2-n, The first requirement speaks to the earlier example, in which an opponent is, able to construct a new message to match a given tag, even though the opponent, does not know and does not learn the key. The second requirement deals with the, need to thwart a brute-force attack based on chosen plaintext. That is, if we assume
Page 394 :
12.4 / SECURITY OF MACs, , 393, , that the opponent does not know K but does have access to the MAC function and, can present messages for MAC generation, then the opponent could try various, messages until finding one that matches a given tag. If the MAC function exhibits, uniform distribution, then a brute-force method would require, on average, 2(n - 1), attempts before finding a message that fits a given tag., The final requirement dictates that the authentication algorithm should not be, weaker with respect to certain parts or bits of the message than others. If this were, not the case, then an opponent who had M and MAC(K, M) could attempt variations on M at the known “weak spots” with a likelihood of early success at producing a new message that matched the old tags., , 12.4 SECURITY OF MACs, Just as with encryption algorithms and hash functions, we can group attacks on, MACs into two categories: brute-force attacks and cryptanalysis., , Brute-Force Attacks, A brute-force attack on a MAC is a more difficult undertaking than a brute-force, attack on a hash function because it requires known message-tag pairs. Let us see, why this is so. To attack a hash code, we can proceed in the following way. Given, a fixed message x with n-bit hash code h = H(x), a brute-force method of finding, a collision is to pick a random bit string y and check if H(y) = H(x). The attacker, can do this repeatedly off line. Whether an off-line attack can be used on a MAC, algorithm depends on the relative size of the key and the tag., To proceed, we need to state the desired security property of a MAC algorithm, which can be expressed as follows., ■, , Computation resistance: Given one or more text-MAC pairs [xi, MAC(K, xi)],, it is computationally infeasible to compute any text-MAC pair [x, MAC(K, x)], for any new input x ≠ xi., , In other words, the attacker would like to come up with the valid MAC code for a, given message x. There are two lines of attack possible: attack the key space and attack the MAC value. We examine each of these in turn., If an attacker can determine the MAC key, then it is possible to generate a, valid MAC value for any input x. Suppose the key size is k bits and that the attacker, has one known text-tag pair. Then the attacker can compute the n-bit tag on the, known text for all possible keys. At least one key is guaranteed to produce the correct tag, namely, the valid key that was initially used to produce the known text-tag, pair. This phase of the attack takes a level of effort proportional to 2k (that is, one, operation for each of the 2k possible key values). However, as was described earlier,, because the MAC is a many-to-one mapping, there may be other keys that produce, the correct value. Thus, if more than one key is found to produce the correct value,, additional text-tag pairs must be tested. It can be shown that the level of effort, drops off rapidly with each additional text-MAC pair and that the overall level of, effort is roughly 2k [MENE97].
Page 395 :
394, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , An attacker can also work on the tag without attempting to recover the key., Here, the objective is to generate a valid tag for a given message or to find a message, that matches a given tag. In either case, the level of effort is comparable to that for, attacking the one-way or weak collision-resistant property of a hash code, or 2n., In the case of the MAC, the attack cannot be conducted off line without further, input; the attacker will require chosen text-tag pairs or knowledge of the key., To summarize, the level of effort for brute-force attack on a MAC algorithm, can be expressed as min(2k, 2n). The assessment of strength is similar to that for, symmetric encryption algorithms. It would appear reasonable to require that the, key length and tag length satisfy a relationship such as min(k, n) Ú N, where N is, perhaps in the range of 128 bits., , Cryptanalysis, As with encryption algorithms and hash functions, cryptanalytic attacks on MAC, algorithms seek to exploit some property of the algorithm to perform some attack, other than an exhaustive search. The way to measure the resistance of a MAC algorithm to cryptanalysis is to compare its strength to the effort required for a bruteforce attack. That is, an ideal MAC algorithm will require a cryptanalytic effort, greater than or equal to the brute-force effort., There is much more variety in the structure of MACs than in hash functions,, so it is difficult to generalize about the cryptanalysis of MACs. Furthermore, far less, work has been done on developing such attacks. A useful survey of some methods, for specific MACs is [PREN96]., , 12.5 MACs BASED ON HASH FUNCTIONS: HMAC, Later in this chapter, we look at examples of a MAC based on the use of a symmetric, block cipher. This has traditionally been the most common approach to constructing, a MAC. In recent years, there has been increased interest in developing a MAC derived from a cryptographic hash function. The motivations for this interest are, 1. Cryptographic hash functions such as MD5 and SHA generally execute faster, in software than symmetric block ciphers such as DES., 2. Library code for cryptographic hash functions is widely available., With the development of AES and the more widespread availability of code, for encryption algorithms, these considerations are less significant, but hash-based, MACs continue to be widely used., A hash function such as SHA was not designed for use as a MAC and cannot be used directly for that purpose, because it does not rely on a secret key., There have been a number of proposals for the incorporation of a secret key into, an existing hash algorithm. The approach that has received the most support is, HMAC [BELL96a, BELL96b]. HMAC has been issued as RFC 2104, has been, chosen as the mandatory-to-implement MAC for IP security, and is used in other, Internet protocols, such as SSL. HMAC has also been issued as a NIST standard, (FIPS 198).
Page 396 :
12.5 / MACs BASED ON HASH FUNCTIONS: HMAC, , 395, , HMAC Design Objectives, RFC 2104 lists the following design objectives for HMAC., ■, , ■, ■, ■, ■, , To use, without modifications, available hash functions. In particular, to use, hash functions that perform well in software and for which code is freely and, widely available., To allow for easy replaceability of the embedded hash function in case faster, or more secure hash functions are found or required., To preserve the original performance of the hash function without incurring a, significant degradation., To use and handle keys in a simple way., To have a well understood cryptographic analysis of the strength of the authentication mechanism based on reasonable assumptions about the embedded hash function., , The first two objectives are important to the acceptability of HMAC. HMAC, treats the hash function as a “black box.” This has two benefits. First, an existing implementation of a hash function can be used as a module in implementing HMAC., In this way, the bulk of the HMAC code is prepackaged and ready to use without, modification. Second, if it is ever desired to replace a given hash function in an, HMAC implementation, all that is required is to remove the existing hash function, module and drop in the new module. This could be done if a faster hash function, were desired. More important, if the security of the embedded hash function were, compromised, the security of HMAC could be retained simply by replacing the embedded hash function with a more secure one (e.g., replacing SHA-2 with SHA-3)., The last design objective in the preceding list is, in fact, the main advantage, of HMAC over other proposed hash-based schemes. HMAC can be proven secure, provided that the embedded hash function has some reasonable cryptographic, strengths. We return to this point later in this section, but first we examine the structure of HMAC., , HMAC Algorithm, Figure 12.5 illustrates the overall operation of HMAC. Define the following terms., H = embedded hash function (e.g., MD5, SHA-1, RIPEMD-160), IV = initial value input to hash function, M = message input to HMAC (including the padding specified in the embedded, hash function), Yi = i th block of M, 0 … i … (L - 1), L = number of blocks in M, b = number of bits in a block, n = length of hash code produced by embedded hash function, K = secret key; recommended length is Ú n; if key length is greater than b, the, key is input to the hash function to produce an n-bit key, K + = K padded with zeros on the left so that the result is b bits in length
Page 397 :
396, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , K+, , ipad, , b bits, , b bits, , b bits, , Y0, , Y1, , YL–1, , Si, , IV, , K+, , n bits, , Hash, n bits, , opad, , H(Si || M), b bits, , Pad to b bits, , So, , IV, , n bits, , Hash, n bits, , HMAC(K, M), Figure 12.5, , HMAC Structure, , ipad = 00110110 (36 in hexadecimal) repeated b/8 times, opad = 01011100 (5C in hexadecimal) repeated b/8 times, Then HMAC can be expressed as, HMAC(K, M) = H[(K + ⊕ opad) } H[(K + ⊕ ipad) } M]], We can describe the algorithm as follows., 1. Append zeros to the left end of K to create a b-bit string K + (e.g., if K is of, length 160 bits and b = 512, then K will be appended with 44 zeroes)., 2., 3., 4., 5., 6., 7., , XOR (bitwise exclusive-OR) K + with ipad to produce the b-bit block Si., Append M to Si., Apply H to the stream generated in step 3., XOR K + with opad to produce the b-bit block So., Append the hash result from step 4 to So., Apply H to the stream generated in step 6 and output the result., , Note that the XOR with ipad results in flipping one-half of the bits of K., Similarly, the XOR with opad results in flipping one-half of the bits of K, using a
Page 398 :
12.5 / MACs BASED ON HASH FUNCTIONS: HMAC, , 397, , different set of bits. In effect, by passing Si and So through the compression function, of the hash algorithm, we have pseudorandomly generated two keys from K., HMAC should execute in approximately the same time as the embedded hash, function for long messages. HMAC adds three executions of the hash compression, function (for Si, So, and the block produced from the inner hash)., A more efficient implementation is possible, as shown in Figure 12.6. Two, quantities are precomputed:, f(IV, (K + ⊕ ipad)), f(IV, (K + ⊕ opad)), where f(cv, block) is the compression function for the hash function, which takes as, arguments a chaining variable of n bits and a block of b bits and produces a chaining variable of n bits. These quantities only need to be computed initially and every, time the key changes. In effect, the precomputed quantities substitute for the initial, value (IV) in the hash function. With this implementation, only one additional instance of the compression function is added to the processing normally produced, , Precomputed, K+, , Computed per message, , ipad, , Si, , b bits, , b bits, , b bits, , Y0, , Y1, , YL–1, , b bits, , IV, , n bits, , f, , Hash, n bits, , K+, , opad, , H(Si || M), Pad to b bits, , So, b bits, , IV, , f, , n bits, , f, n bits, , HMAC(K, M), Figure 12.6, , Hiva-Network.Com, , Efficient Implementation of HMAC
Page 399 :
398, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , by the hash function. This more efficient implementation is especially worthwhile if, most of the messages for which a MAC is computed are short., , Security of HMAC, The security of any MAC function based on an embedded hash function depends, in some way on the cryptographic strength of the underlying hash function. The, appeal of HMAC is that its designers have been able to prove an exact relationship between the strength of the embedded hash function and the strength of, HMAC., The security of a MAC function is generally expressed in terms of the probability of successful forgery with a given amount of time spent by the forger and, a given number of message-tag pairs created with the same key. In essence, it is, proved in [BELL96a] that for a given level of effort (time, message–tag pairs) on, messages generated by a legitimate user and seen by the attacker, the probability, of successful attack on HMAC is equivalent to one of the following attacks on the, embedded hash function., 1. The attacker is able to compute an output of the compression function even, with an IV that is random, secret, and unknown to the attacker., 2. The attacker finds collisions in the hash function even when the IV is random, and secret., In the first attack, we can view the compression function as equivalent to the, hash function applied to a message consisting of a single b-bit block. For this attack,, the IV of the hash function is replaced by a secret, random value of n bits. An attack, on this hash function requires either a brute-force attack on the key, which is a level, of effort on the order of 2n, or a birthday attack, which is a special case of the second, attack, discussed next., In the second attack, the attacker is looking for two messages M and M′ that, produce the same hash: H(M) = H(M′). This is the birthday attack discussed in, Chapter 11. We have shown that this requires a level of effort of 2n/2 for a hash, length of n. On this basis, the security of MD5 is called into question, because a, level of effort of 264 looks feasible with today’s technology. Does this mean that, a 128-bit hash function such as MD5 is unsuitable for HMAC? The answer is no,, because of the following argument. To attack MD5, the attacker can choose any, set of messages and work on these off line on a dedicated computing facility to, find a collision. Because the attacker knows the hash algorithm and the default IV,, the attacker can generate the hash code for each of the messages that the attacker, generates. However, when attacking HMAC, the attacker cannot generate message/code pairs off line because the attacker does not know K. Therefore, the attacker must observe a sequence of messages generated by HMAC under the same, key and perform the attack on these known messages. For a hash code length of, 128 bits, this requires 264 observed blocks (272 bits) generated using the same key., On a 1-Gbps link, one would need to observe a continuous stream of messages, with no change in key for about 150,000 years in order to succeed. Thus, if speed, is a concern, it is fully acceptable to use MD5 rather than SHA-1 as the embedded, hash function for HMAC.
Page 400 :
12.6 / MACs BASED ON BLOCK CIPHERS: DAA AND CMAC, , 399, , 12.6 MACs BASED ON BLOCK CIPHERS: DAA AND CMAC, In this section, we look at two MACs that are based on the use of a block cipher, mode of operation. We begin with an older algorithm, the Data Authentication, Algorithm (DAA), which is now obsolete. Then we examine CMAC, which is designed to overcome the deficiencies of DAA., , Data Authentication Algorithm, The Data Authentication Algorithm (DAA), based on DES, has been one of the, most widely used MACs for a number of years. The algorithm is both a FIPS publication (FIPS PUB 113) and an ANSI standard (X9.17). However, as we discuss, subsequently, security weaknesses in this algorithm have been discovered, and it is, being replaced by newer and stronger algorithms., The algorithm can be defined as using the cipher block chaining (CBC) mode, of operation of DES (Figure 6.4) with an initialization vector of zero. The data (e.g.,, message, record, file, or program) to be authenticated are grouped into contiguous, 64-bit blocks: D1, D2, c , DN. If necessary, the final block is padded on the right, with zeroes to form a full 64-bit block. Using the DES encryption algorithm E and a, secret key K, a data authentication code (DAC) is calculated as follows (Figure 12.7)., O1 = E(K, D), O2 = E(K, [D2 ⊕ O1]), O3 = E(K, [D3 ⊕ O2]), , #, #, #, , ON = E(K, [DN ⊕ ON - 1]), , K, (56 bits), , Time = 1, , Time = 2, , Time = N – 1, , Time = N, , D1, (64 bits), , D2, , DN–1, , DN, , +, , +, , +, , DES, encrypt, , O1, (64 bits), , K, , DES, encrypt, , K, , O2, , DES, encrypt, , ON–1, , K, , DES, encrypt, , ON, DAC, (16 to 64 bits), , Figure 12.7, , Data Authentication Algorithm (FIPS PUB 113)
Page 401 :
400, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , The DAC consists of either the entire block ON or the leftmost M bits of the, block, with 16 … M … 64., , Cipher-Based Message Authentication Code (CMAC), As was mentioned, DAA has been widely adopted in government and industry., [BELL00] demonstrated that this MAC is secure under a reasonable set of security, criteria, with the following restriction. Only messages of one fixed length of mn bits, are processed, where n is the cipher block size and m is a fixed positive integer. As, a simple example, notice that given the CBC MAC of a one-block message X, say, T = MAC(K, X), the adversary immediately knows the CBC MAC for the twoblock message X } (X ⊕ T) since this is once again T., Black and Rogaway [BLAC00] demonstrated that this limitation could be, overcome using three keys: one key K of length k to be used at each step of the, cipher block chaining and two keys of length b, where b is the cipher block length., This proposed construction was refined by Iwata and Kurosawa so that the two, n-bit keys could be derived from the encryption key, rather than being provided, separately [IWAT03]. This refinement, adopted by NIST, is the Cipher-based, Message Authentication Code (CMAC) mode of operation for use with AES and, triple DES. It is specified in NIST Special Publication 800-38B., First, let us define the operation of CMAC when the message is an integer, multiple n of the cipher block length b. For AES, b = 128, and for triple DES,, b = 64. The message is divided into n blocks (M1, M2, c , Mn). The algorithm, makes use of a k-bit encryption key K and a b-bit constant, K1. For AES, the key, size k is 128, 192, or 256 bits; for triple DES, the key size is 112 or 168 bits. CMAC is, calculated as follows (Figure 12.8)., C1 = E(K, M1), C2 = E(K, [M2 ⊕ C1]), C3 = E(K, [M3 ⊕ C2]), , #, #, #, Cn = E(K, [Mn ⊕ Cn - 1 ⊕ K1]), T = MSB Tlen(Cn), where, T, = message authentication code, also referred to as the tag, Tlen, = bit length of T, MSB s(X) = the s leftmost bits of the bit string X, If the message is not an integer multiple of the cipher block length, then the, final block is padded to the right (least significant bits) with a 1 and as many 0s as, necessary so that the final block is also of length b. The CMAC operation then proceeds as before, except that a different b-bit key K2 is used instead of K1.
Page 402 :
12.6 / MACs BASED ON HASH FUNCTIONS: HMAC, M1, , M2, , 401, , Mn, , b, , K1, , k, K, , Encrypt, , K, , Encrypt, , K, , Encrypt, , MSB(Tlen), , T, , (a) Message length is integer multiple of block size, M1, , Mn, , M2, , 10...0, , K2, , K, , Encrypt, , K, , Encrypt, , K, , Encrypt, , MSB(Tlen), , T, , (b) Message length is not integer multiple of block size, Figure 12.8, , Cipher-Based Message Authentication Code (CMAC), , The two b-bit keys are derived from the k-bit encryption key as follows., L = E(K, 0b), K1 = L # x, K2 = L # x2 = (L # x) # x, where multiplication ( # ) is done in the finite field GF(2b) and x and x2 are first- and, second-order polynomials that are elements of GF(2b). Thus, the binary representation of x consists of b - 2 zeros followed by 10; the binary representation of x2, consists of b - 3 zeros followed by 100. The finite field is defined with respect to, an irreducible polynomial that is lexicographically first among all such polynomials, with the minimum possible number of nonzero terms. For the two approved block, sizes, the polynomials are x64 + x4 + x3 + x + 1 and x128 + x7 + x2 + x + 1., To generate K1 and K2, the block cipher is applied to the block that consists, entirely of 0 bits. The first subkey is derived from the resulting ciphertext by a, left shift of one bit and, conditionally, by XORing a constant that depends on the, block size. The second subkey is derived in the same manner from the first subkey., This property of finite fields of the form GF(2b) was explained in the discussion of, MixColumns in Chapter 6.
Page 403 :
402, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , 12.7 AUTHENTICATED ENCRYPTION: CCM AND GCM, Authenticated encryption (AE) is a term used to describe encryption systems that, simultaneously protect confidentiality and authenticity (integrity) of communications. Many applications and protocols require both forms of security, but until recently the two services have been designed separately., There are four common approaches to providing both confidentiality and encryption for a message M., ■, , ■, , ■, , ■, , Hashing followed by encryption (H S E): First compute the cryptographic, hash function over M as h = H(M). Then encrypt the message plus hash function: E(K, (M } h))., Authentication followed by encryption (A S E): Use two keys. First authenticate the plaintext by computing the MAC value as T = MAC(K1, M). Then, encrypt the message plus tag: E(K2, [M } T ]). This approach is taken by the, SSL/TLS protocols (Chapter 17)., Encryption followed by authentication (E S A): Use two keys. First encrypt, the message to yield the ciphertext C = E(K2, M). Then authenticate the, ciphertext with T = MAC(K1, C) to yield the pair (C, T). This approach is, used in the IPSec protocol (Chapter 20)., Independently encrypt and authenticate (E + A). Use two keys. Encrypt, the message to yield the ciphertext C = E(K2, M). Authenticate the plaintext with T = MAC(K1, M) to yield the pair (C, T). These operations can, be performed in either order. This approach is used by the SSH protocol, (Chapter 17)., , Both decryption and verification are straightforward for each approach. For, H S E, A S E, and E + A, decrypt first, then verify. For E S A, verify first, then, decrypt. There are security vulnerabilities with all of these approaches. The H S E, approach is used in the Wired Equivalent Privacy (WEP) protocol to protect WiFi, networks. This approach had fundamental weaknesses and led to the replacement of, the WEP protocol. [BLAC05] and [BELL00] point out that there are security concerns in each of the three encryption/MAC approaches listed above. Nevertheless,, with proper design, any of these approaches can provide a high level of security., This is the goal of the two approaches discussed in this section, both of which have, been standardized by NIST., , Counter with Cipher Block Chaining-Message, Authentication Code, The CCM mode of operation was standardized by NIST specifically to support the security requirements of IEEE 802.11 WiFi wireless local area networks, (Chapter 18), but can be used in any networking application requiring authenticated encryption. CCM is a variation of the encrypt-and-MAC approach to authenticated encryption. It is defined in NIST SP 800-38C., The key algorithmic ingredients of CCM are the AES encryption algorithm, (Chapter 6), the CTR mode of operation (Chapter 7), and the CMAC authentication
Page 404 :
12.7 / AUTHENTICATED ENCRYPTION: CCM AND GCM, , 403, , algorithm (Section 12.6). A single key K is used for both encryption and MAC algorithms. The input to the CCM encryption process consists of three elements., 1. Data that will be both authenticated and encrypted. This is the plaintext message P of data block., 2. Associated data A that will be authenticated but not encrypted. An example, is a protocol header that must be transmitted in the clear for proper protocol, operation but which needs to be authenticated., 3. A nonce N that is assigned to the payload and the associated data. This is a, unique value that is different for every instance during the lifetime of a protocol association and is intended to prevent replay attacks and certain other, types of attacks., Figure 12.9 illustrates the operation of CCM. For authentication, the input, includes the nonce, the associated data, and the plaintext. This input is formatted, as a sequence of blocks B0 through Br. The first block contains the nonce plus some, formatting bits that indicate the lengths of the N, A, and P elements. This is followed by zero or more blocks that contain A, followed by zero of more blocks that, contain P. The resulting sequence of blocks serves as input to the CMAC algorithm,, which produces a MAC value with length Tlen, which is less than or equal to the, block length (Figure 12.9a)., For encryption, a sequence of counters is generated that must be independent, of the nonce. The authentication tag is encrypted in CTR mode using the single, counter Ctr0. The Tlen most significant bits of the output are XORed with the tag to, produce an encrypted tag. The remaining counters are used for the CTR mode encryption of the plaintext (Figure 7.7). The encrypted plaintext is concatenated with, the encrypted tag to form the ciphertext output (Figure 12.9b)., SP 800-38C defines the authentication/encryption process as follows., Apply the formatting function to (N, A, P) to produce the blocks B0, B1, c , Br., Set Y0 = E(K, B0)., For i = 1 to r, do Yi = E(K, (Bi ⊕ Yi - 1))., Set T = MSB Tlen(Yr)., Apply the counter generation function to generate the counter blocks, Ctr0, Ctr1, c , Ctrm, where m = < Plen/128 = ., 6. For j = 0 to m, do Sj = E(K, Ctrj)., 7. Set S = S1 } S2 } g } Sm., 8. Return C = (P ⊕ MSB Plen(S)) } (T ⊕ MSB Tlen(S0))., , 1., 2., 3., 4., 5., , For decryption and verification, the recipient requires the following input: the, ciphertext C, the nonce N, the associated data A, the key K, and the initial counter, Ctr0. The steps are as follows., 1. If Clen … Tlen, then return INVALID., 2. Apply the counter generation function to generate the counter blocks, Ctr0, Ctr1, c , Ctrm, where m = < Clen/128 = ., 3. For j = 0 to m, do Sj = E(K, Ctrj).
Page 406 :
12.7 / AUTHENTICATED ENCRYPTION: CCM AND GCM, , 405, , CCM is a relatively complex algorithm. Note that it requires two complete, passes through the plaintext, once to generate the MAC value, and once for encryption. Further, the details of the specification require a tradeoff between the length, of the nonce and the length of the tag, which is an unnecessary restriction. Also note, that the encryption key is used twice with the CTR encryption mode: once to generate the tag and once to encrypt the plaintext plus tag. Whether these complexities, add to the security of the algorithm is not clear. In any case, two analyses of the, algorithm ([JONS02] and [ROGA03]) conclude that CCM provides a high level of, security., , Galois/Counter Mode, The GCM mode of operation, standardized by NIST in NIST SP 800-38D, is designed to be parallelizable so that it can provide high throughput with low cost and, low latency. In essence, the message is encrypted in variant of CTR mode. The resulting ciphertext is multiplied with key material and message length information, over GF(2128) to generate the authenticator tag. The standard also specifies a mode, of operation that supplies the MAC only, known as GMAC., The GCM mode makes use of two functions: GHASH, which is a keyed hash, function, and GCTR, which is essentially the CTR mode with the counters determined by a simple increment by one operation., GHASH H(X) takes a input the hash key H and a bit string X such that, len(X) = 128m bits for some positive integer m and produces a 128-bit MAC value., The function may be specified as follows (Figure 12.10a)., 1. Let X1, X2, c , Xm - 1, Xm denote the unique sequence of blocks such that, X = X1 } X2 } g } Xm - 1 } Xm., 2. Let Y0 be a block of 128 zeros, designated as 0128., 3. For i = 1, c , m, let Yi = (Yi - 1 ⊕ Xi) # H, where # designates multiplication, in GF(2128)., 4. Return Ym., The GHASH H(X) function can be expressed as, (X1 # Hm) ⊕ (X2 # Hm - 1) ⊕ g ⊕ (Xm - 1 # H2) ⊕ (Xm # H), This formulation has desirable performance implications. If the same hash key, is to be used to authenticate multiple messages, then the values H2, H3, c can be, precalculated one time for use with each message to be authenticated. Then, the, blocks of the data to be authenticated (X1, X2, c , Xm) can be processed in parallel, because the computations are independent of one another., GCTRK(ICB, X) takes a input a secret key K and a bit string X arbitrary, length and returns a ciphertext Y of bit length (X). The function may be specified as, follows (Figure 12.10b)., 1. If X is the empty string, then return the empty string as Y., 2. Let n = < (len(X)/128) = . That is, n is the smallest integer greater than or equal, to (X)/128.
Page 409 :
408, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , In step 1, the hash key is generated by encrypting a block of all zeros with, the secret key K. In step 2, the pre-counter block (J0) is generated from the IV., In particular, when the length of the IV is 96 bits, then the padding string 031 } 1, is appended to the IV to form the pre-counter block. Otherwise, the IV is padded, with the minimum number of 0 bits, possibly none, so that the length of the resulting string is a multiple of 128 bits (the block size); this string in turn is appended, with 64 additional 0 bits, followed by the 64-bit representation of the length of, the IV, and the GHASH function is applied to the resulting string to form the, pre-counter block., Thus, GCM is based on the CTR mode of operation and adds a MAC that authenticates both the message and additional data that requires only authentication., The function that computes the hash uses only multiplication in a Galois field. This, choice was made because the operation of multiplication is easy to perform within a, Galois field and is easily implemented in hardware [MCGR05]., [MCGR04] examines the available block cipher modes of operation and, shows that a CTR-based authenticated encryption approach is the most efficient, mode of operation for high-speed packet networks. The paper further demonstrates, that GCM meets a high level of security requirements., , 12.8 KEY WRAPPING, Background, The most recent block cipher mode of operation defined by NIST is the Key Wrap, (KW) mode of operation (SP 800-38F), which uses AES or triple DEA as the underlying encryption algorithm. The AES version is also documented in RFC 3394., The purpose of key wrapping is to securely exchange a symmetric key to be, shared by two parties, using a symmetric key already shared by those parties. The, latter key is called a key encryption key (KEK)., Two questions need to be addressed at this point. First, why do we need to, use a symmetric key already known to two parties to encrypt a new symmetric key?, Such a requirement is found in a number of protocols described in this book, such, as the key management portion of IEEE 802.11 and IPsec. Quite often, a protocol, calls for a hierarchy of keys, with keys lower on the hierarchy used more frequently,, and changed more frequently to thwart attacks. A higher-level key, which is used infrequently and therefore more resistant to cryptanalysis, is used to encrypt a newly, created lower-level key so that it can be exchanged between parties that share the, higher-level key., The second question is, why do we need a new mode? The intent of the new, mode is to operate on keys whose length is greater than the block size of the encryption algorithm. For example, AES uses a block size of 128 bits but can use a key, size of 128, 192, or 256 bits. In the latter two cases, encryption of the key involves, multiple blocks. We consider the value of key data to be greater than the value of, other data, because the key will be used multiple times, and compromise of the, key compromises all of the data encrypted with the key. Therefore, NIST desired
Page 410 :
12.8 / KEY WRAPPING, , 409, , a robust encryption mode. KW is robust in the sense that each bit of output can be, expected to depend in a nontrivial fashion on each bit of input. This is not the case, for any of the other modes of operation that we have described. For example, in, all of the modes so far described, the last block of plaintext only influences the last, block of ciphertext. Similarly, the first block of ciphertext is derived only from the, first block of plaintext., To achieve this robust operation, KW achieves a considerably lower throughput than the other modes, but the tradeoff may be appropriate for some key, management applications. Also, KW is only used for small amounts of plaintext, compared to, say, the encryption of a message or a file., , The Key Wrapping Algorithm, The key wrapping algorithm operates on blocks of 64 bits. The input to the algorithm consists of a 64-bit constant, discussed subsequently, and a plaintext key that, is divided into blocks of 64 bits. We use the following notation:, MSB 64(W) most significant 64 bits of W, LSB 64(W), , least significant 64 bits of W, , W, , temporary value; output of encryption function, , ⊕, , bitwise exclusive-OR, , }, , concatenation, , K, , key encryption key, , n, , number of 64-bit key data blocks, , s, , number of stages in the wrapping process; s = 6n, , Pi, , ith plaintext key data block; 1 … i … n, , Ci, , ith ciphertext data block; 0 … i … n, , A(t), , 64-bit integrity check register after encryption stage t; 1 … t … s, , A(0), , initial integrity check value (ICV); in hexadecimal:, A6A6A6A6A6A6A6A6, , R(t, i), , 64-bit register i after encryption stage t; 1 … t … s; 1 … i … n, , We now describe the key wrapping algorithm:, Inputs:, , Plaintext, n 64-bit values (P1, P2, c , Pn), Key encryption key, K, , Outputs: Ciphertext, (n + 1) 64-bit values (C0, C1, c , Cn), 1. Initialize variables., A(0) = A6A6A6A6A6A6A6A6, for i = 1 to n, R(0, i) = Pi
Page 411 :
410, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , 2. Calculate intermediate values., for t = 1 to s, W = E(K, [A(t−1) } R(t−1, 1)]), A(t) = t ⊕ MSB64(W), R(t, n) = LSB64(W), for i = 1 to n−1, R(t, i) = R(t−1, i+1), 3. Output results., C0 = A(s), for i = 1 to n, Ci = R(s, i), Note that the ciphertext is one block longer than the plaintext key, to accommodate the ICV. Upon unwrapping (decryption), both the 64-bit ICV and the, plaintext key are recovered. If the recovered ICV differs from the input value of, hexadecimal A6A6A6A6A6A6A6A6, then an error or alteration has been detected, and the plaintext key is rejected. Thus, the key wrap algorithm provides not only, confidentiality but also data integrity., Figure 12.12 illustrated the key wrapping algorithm for encrypting a 256-bit, key. Each box represents one encryption stage (one value of t). Note that the A, output is fed as input to the next stage (t + 1), whereas the R output skips forward, n stages (t + n), which in this example is n = 4. This arrangement further increases, the avalanche effect and the mixing of bits. To achieve this skipping of stages, a sliding buffer is used, so that the R output from stage t is shifted in the buffer one position for each stage, until it becomes the input for stage t + n. This might be clearer, if we expand the inner for loop for a 256-bit key (n = 4). Then the assignments are, as follows:, R(t, 1) = R(t - 1, 2), R(t, 2) = R(t - 1, 3), R(t, 3) = R(t - 1, 4), For example, consider that at stage 5, the R output has a value of R(5, 4) = x., At stage 6, we execute R(6, 3) = R(5, 4) = x. At stage 7, we execute R(7, 2) = R, (6, 3) = x. At stage 8, we execute R(8, 1) = R(7, 2) = x. So, at stage 9, the input, value of R(t - 1, 1) is R(8, 1) = x., Figure 12.13 depicts the operation of stage t for a 256-bit key. The dashed, feedback lines indicate the assignment of new values to the stage variables., , Key Unwrapping, The key unwrapping algorithm can be defined as follows:, Ciphertext, (n + 1) 64-bit values (C0, C1, c , Cn), Key encryption key, K, Outputs: Plaintext, n 64-bit values (P1, P2, c , Pn), ICV, Inputs:
Page 412 :
12.8 / KEY WRAPPING, , P1 =, A(0) R(0, 1), , P2 =, A(1) R(0, 2), , P3 =, A(2) R(0, 3), , P4 =, A(3) R(0, 4), , t=1, , t=2, , t=3, , t=4, , t=5, , t=6, , t=7, , t=8, , t=9, , t = 10, , t = 11, , t = 12, , t = 13, , t = 14, , t = 15, , t = 16, , t = 17, , t = 18, , t = 19, , t = 20, , t = 21, , t = 22, , t = 23, , t = 24, , C2 = R(24, 2), = R(22, 4), , C3 = R(24, 3), = R(23, 4), , C0 = A(24) C1 = R(24, 1), = R(21, 4), Figure 12.12, , Key Wrapping Operation for 256-Bit Key, , 1. Initialize variables., A(s) = C0, for i = 1 to n, R(s, i) = Ci, 2. Calculate intermediate values., for t = s to 1, W = D(K, [(A(t) ⊕ t) } R(t, n)]), , 411, , C4 = R(24, 4)
Page 413 :
412, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, A(t – 1), , R(t – 1, 1), , R(t – 1, 2), , R(t – 1, 3), , K, , Encrypt, R(t – 1, 4), , t, , MSB, , Figure 12.13, , LSB, , Key Wrapping Operation for 256-Bit Key: Stage t, , A(t–1) = MSB64(W), R(t–1, 1) = LSB64(W), for i = 2 to n, R(t–1, i) = R(t, i–1), 3. Output results., if A(0) = A6A6A6A6A6A6A6A6, then, for i = 1 to n, P(i) = R(0, i), else, return error, Note that the decryption function is used in the unwrapping algorithm., We now demonstrate that the unwrap function is the inverse of the wrap function, that is, that the unwrap function recovers the plaintext key and the ICV. First,, note that because the index variable t is counted down from s to 1 for unwrapping,, stage t of the unwrap algorithm corresponds to stage t of the wrap algorithm. The, input variables to stage t of the wrap algorithm are indexed at t - 1 and the output, variables of stage t of the unwrap algorithm are indexed at t - 1. Thus, to demonstrate that the two algorithms are inverses of each other, we need only demonstrate, that the output variables of stage t of the unwrap algorithm are equal to the input, variables to stage t of the wrap algorithm., This demonstration is in two parts. First we demonstrate that the calculation, of A and R variables prior to the for loop are inverses. To do this, let us simplify, the notation a bit. Define the 128-bit value T to be the 64-bit value t followed by 64, zeros. Then, the first three lines of step 2 of the wrap algorithm can be written as the, following single line:, A(t) } R(t, n) = T ⊕ E(K, [A(t - 1) } R(t - 1, 1)]), , (12.1), , The first three lines of step 2 of the unwrap algorithm can be written as:, A(t - 1) } R(t - 1, 1) = D(K, ([A(t) } R(t, n)] ⊕ T)), , (12.2)
Page 414 :
12.9 / PSEUDORANDOM NUMBER GENERATION USING HASH FUNCTIONS, , 413, , Expanding the right-hand side by substituting from Equation 12.1,, D(K, ([A(t) } R(t, n)] ⊕ T)) = D(K, ([T ⊕ E(K, [A(t - 1) } R(t - 1, 1)])] ⊕ T)), Now we recognize that T ⊕ T = 0 and that for any x, x ⊕ 0 = x. So,, D(K, ([A(t) } R(t, n)] ⊕ T)) = D(K, ([E(K, [A(t - 1) } R(t - 1, 1)])), = A(t - 1) } R(t - 1, 1), The second part of the demonstration is to show that the for loops in step 2, of the wrap and unwrap algorithms are inverses. For stage k of the wrap algorithm,, the variables R(t - 1, 1) through R(t - 1, n) are input. R(t - 1, 1) is used in the, encryption calculation. R(t - 1, 2) through R(t - 1, n) are mapped, respectively, into R(t, 1) through R(t, n - 1), and R(t, n) is output from the encryption function., For stage k of the unwrap algorithm, the variables R(t, 1) through R(t, n) are input., R(t, n) is input to the decryption function to produce R(t - 1, 1). The remaining, variables R(t - 1, 2) through R(t - 1, n) are generated by the for loop, such that, they are mapped, respectively, from R(t, 1) through R(t, n - 1)., Thus, we have shown that the output variables of stage k of the unwrap algorithm equal the input variables of stage k of the wrap algorithm., , 12.9 PSEUDORANDOM NUMBER GENERATION USING HASH, FUNCTIONS AND MACs, The essential elements of any pseudorandom number generator (PRNG) are a seed, value and a deterministic algorithm for generating a stream of pseudorandom bits., If the algorithm is used as a pseudorandom function (PRF) to produce a required, value, such as a session key, then the seed should only be known to the user of the, PRF. If the algorithm is used to produce a stream encryption function, then the seed, has the role of a secret key that must be known to the sender and the receiver., We noted in Chapters 8 and 10 that, because an encryption algorithm produces an apparently random output, it can serve as the basis of a (PRNG). Similarly,, a hash function or MAC produces apparently random output and can be used to, build a PRNG. Both ISO standard 18031 (Random Bit Generation) and NIST SP, 800-90 (Recommendation for Random Number Generation Using Deterministic, Random Bit Generators) define an approach for random number generation using, a cryptographic hash function. SP 800-90 also defines a random number generator, based on HMAC. We look at these two approaches in turn., , PRNG Based on Hash Function, Figure 12.14a shows the basic strategy for a hash-based PRNG specified in SP 80090 and ISO 18031. The algorithm takes as input:, V = seed, seedlen = bit length of V Ú K + 64, where k is a desired security level, expressed in bits, n = desired number of output bits
Page 415 :
414, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , V, , +1, , Cryptographic, hash function, , Pseudorandom, output, (a) PRNG using cryptographic hash function, , V, , K, , HMAC, , Pseudorandom, output, , (b) PRNG using HMAC, , Figure 12.14 Basic Structure of Hash-Based PRNGs (SP 800-90), , The algorithm uses the cryptographic hash function H with an hash value output of outlen bits. The basic operation of the algorithm is, m = < n/outlen =, data = V, W = the null string, For i = 1 to m, wi = H (data), W = } wi, data = (data + 1) mod 2seedlen, Return leftmost n bits of W, Thus, the pseudorandom bit stream is w1 } w2 } c } wm with the final block, truncated if required., The SP 800-90 specification also provides for periodically updating V to enhance security. The specification also indicates that there are no known or suspected, weaknesses in the hash-based approach for a strong cryptographic hash algorithm,, such as SHA-2.
Page 416 :
12.9 / PSEUDORANDOM NUMBER GENERATION USING HASH FUNCTIONS, , 415, , PRNG Based on MAC Function, Although there are no known or suspected weaknesses in the use of a cryptographic, hash function for a PRNG in the manner of Figure 12.14a, a higher degree of confidence can be achieved by using a MAC. Almost invariably, HMAC is used for, constructing a MAC-based PRNG. This is because HMAC is a widely used standardized MAC function and is implemented in many protocols and applications. As, SP 800-90 points out, the disadvantage of this approach compared to the hash-based, approach is that the execution time is twice as long, because HMAC involves two, executions of the underlying hash function for each output block. The advantage of, the HMAC approach is that it provides a greater degree of confidence in its security, compared to a pure hash-based approach., For the MAC-based approach, there are two inputs: a key K and a seed V. In, effect, the combination of K and V form the overall seed for the PRNG specified, in SP 800-90. Figure 12.14b shows the basic structure of the PRNG mechanism, and, the leftmost column of Figure 12.15 shows the logic. Note that the key remains the, same for each block of output, and the data input for each block is equal to the tag, output of the previous block. The SP 800-90 specification also provides for periodically updating K and V to enhance security., It is instructive to compare the SP 800-90 recommendation with the use of, HMAC for a PRNG in some applications, and this is shown in Figure 12.15. For the, IEEE 802.11i wireless LAN security standard (Chapter 18), the data input consists, of the seed concatenated with a counter. The counter is incremented for each block, wi of output. This approach would seem to offer enhanced security compared to the, SP 800-90 approach. Consider that for SP 800-90, the data input for output block, wi is just the output wi - 1 of the previous execution of HMAC. Thus, an opponent, who is able to observe the pseudorandom output knows both the input and output, of HMAC. Even so, with the assumption that HMAC is secure, knowledge of the, input and output should not be sufficient to recover K and hence not sufficient to, predict future pseudorandom bits., The approach taken by the Transport Layer Security protocol (Chapter 17), and the Wireless Transport Layer Security Protocol (Chapter 18) involves invoking, HMAC twice for each block of output wi. As with IEEE 802.11, this is done in such, a way that the output does not yield direct information about the input. The double, use of HMAC doubles the execution burden and would seem to be security overkill., m = < n/outlen =, w0 = V, W = the null string, For i = 1 to m, wi = MAC(K, wi - 1), W = W } wi, Return leftmost n bits of W, NIST SP 800-90, , m = < n/outlen =, W = the null string, For i = 1 to m, wi = MAC(K, (V } i)), W = W } wi, Return leftmost n bits of W, , IEEE 802.11i, , Figure 12.15 Three PRNGs Based on HMAC, , Hiva-Network.Com, , m = < n/outlen =, A(0) = V, W = the null string, For i = 1 to m, A(i) = MAC(K, A(i - 1)), wi = MAC(K, (A(i) } V), W = W } wi, Return leftmost n bits of W, TLS/WTLS
Page 417 :
416, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, , 12.10 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, authenticator, Cipher-Based Message, Authentication Code, (CMAC), CMAC, Counter with Cipher Block, Chaining-Message, Authentication Code, (CCM), , cryptographic checksum, cryptographic hash, function, Data Authentication, Algorithm (DAA), Galois/Counter Mode, (GCM), HMAC, , key encryption key, Key Wrap mode, key wrapping, message authentication, message authentication code, (MAC), , Review Questions, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7, 12.8, 12.9, , What types of attacks are addressed by message authentication?, What two levels of functionality comprise a message authentication or digital signature mechanism?, What are some approaches to producing message authentication?, When a combination of symmetric encryption and an error control code is used for, message authentication, in what order must the two functions be performed?, What is a message authentication code?, What is the difference between a message authentication code and a one-way hash, function?, In what ways can a hash value be secured so as to provide message authentication?, Is it necessary to recover the secret key in order to attack a MAC algorithm?, What changes in HMAC are required in order to replace one underlying hash function with another?, , Problems, 12.1, , 12.2, , If F is an error-detection function, either internal or external use (Figure 12.2) will, provide error-detection capability. If any bit of the transmitted message is altered,, this will be reflected in a mismatch of the received FCS and the calculated FCS,, whether the FCS function is performed inside or outside the encryption function., Some codes also provide an error-correction capability. Depending on the nature of, the function, if one or a small number of bits is altered in transit, the error-correction, code contains sufficient redundant information to determine the errored bit or bits, and correct them. Clearly, an error-correction code will provide error correction capability when used external to the encryption function. Will it also provide this capability if used internal to the encryption function?, The data authentication algorithm, described in Section 12.6, can be defined as using, the cipher block chaining (CBC) mode of operation of DES with an initialization vector of zero (Figure 12.7). Show that the same result can be produced using the cipher, feedback mode.
Page 418 :
12.10 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, 12.3, , 12.4, , 12.5, , 12.6, , 12.7, , 417, , At the beginning of Section 12.6, it was noted that given the CBC MAC of a oneblock message X, say T = MAC(K, X), the adversary immediately knows the CBC, MAC for the two-block message X } (X ⊕ T) since this is once again T. Justify this, statement., In this problem, we demonstrate that for CMAC, a variant that XORs the second, key after applying the final encryption doesn’t work. Let us consider this for the, case of the message being an integer multiple of the block size. Then, the variant, can be expressed as VMAC(K, M) = CBC(K, M) ⊕ K1. Now suppose an adversary is able to ask for the MACs of three messages: the message 0 = 0n, where n is, the cipher block size; the message 1 = 1n; and the message 1 } 0. As a result of these, three queries, the adversary gets T0 = CBC(K, 0) ⊕ K1; T1 = CBC(K, 1) ⊕ K1 and, T2 = CBC(K, [CBC(K, 1)]) ⊕ K1. Show that the adversary can compute the correct, MAC for the (unqueried) message 0 } (T0 ⊕ T1)., In the discussion of subkey generation in CMAC, it states that the block cipher is applied to the block that consists entirely of 0 bits. The first subkey is derived from the, resulting string by a left shift of one bit and, conditionally, by XORing a constant that, depends on the block size. The second subkey is derived in the same manner from the, first subkey., a. What constants are needed for block sizes of 192-bits and 256 bits?, b. Explain how the left shift and XOR accomplishes the desired result., Section 12.7 listed four general approaches to provide confidentiality and message, encryption: H S E, A S E, E S A, and E + A., a. Which of the above performs decryption before verification?, b. Which of the above performs verification before decryption?, Show that the GHASH function calculates, (X1 # Hm) ⊕ (X2 # Hm - 1) ⊕ g ⊕ (Xm - 1 # H2) ⊕ (Xm # H), , 12.8, 12.9, , Draw a figure similar to Figure 12.11 that shows authenticated decryption., Alice want to send a single bit of information (a yes or a no) to Bob by means of a, word of length 2. Alice and Bob have four possible keys available to perform message authentication. The following matrix shows the 2-bit word sent for each message, under each key:, , Message, Key, , 0, , 1, , 1, , 00, , 11, , 2, , 01, , 10, , 3, , 10, , 01, , 4, , 11, , 00, , a. The preceding matrix is in a useful form for Alice. Construct a matrix with the, same information that would be more useful for Bob., , b. What is the probability that someone else can successfully impersonate Alice?, c. What is the probability that someone can replace an intercepted message with, 12.10, , another message successfully?, Draw figures similar to Figures 12.12 and 12.13 for the unwrap algorithm.
Page 419 :
418, , CHAPTER 12 / MESSAGE AUTHENTICATION CODES, 12.11, , Consider the following key wrapping algorithm:, , 1. Initialize variables., A = A6A6A6A6A6A6A6A6, for i = 1 to n, R(i) = Pi, , 2. Calculate intermediate values., for j = 0 to 5, for i = 1 to n, B = E(K, [A } R(i)]), t = (n × j) + i, A = t ⊕ MSB64(B), R(i) = LSB64(B), , 3. Output results., C0 = A, for i = 1 to n, Ci = R(i), , a. Compare this algorithm, functionally, with the algorithm specified in SP 800-38F, and described in Section 12.8., , b. Write the corresponding unwrap algorithm.
Page 420 :
CHAPTER, , Digital Signatures, 13.1 Digital Signatures, Properties, Attacks and Forgeries, Digital Signature Requirements, Direct Digital Signature, 13.2 Elgamal Digital Signature Scheme, 13.3 Schnorr Digital Signature Scheme, 13.4 NIST Digital Signature Algorithm, The DSA Approach, The Digital Signature Algorithm, 13.5 Elliptic Curve Digital Signature Algorithm, Global Domain Parameters, Key Generation, Digital Signature Generation and Authentication, 13.6 RSA-PSS Digital Signature Algorithm, Mask Generation Function, The Signing Operation, Signature Verification, 13.7 Key Terms, Review Questions, and Problems, , 419
Page 421 :
420, , CHAPTER 13 / DIGITAL SIGNATURES, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, , Present an overview of the digital signature process., Understand the Elgamal digital signature scheme., Understand the Schnorr digital signature scheme., Understand the NIST digital signature scheme., Compare and contrast the NIST digital signature scheme with the Elgamal, and Schnorr digital signature schemes., ◆ Understand the elliptic curve digital signature scheme., ◆ Understand the RSA-PSS digital signature scheme., , The most important development from the work on public-key cryptography is the, digital signature. The digital signature provides a set of security capabilities that would, be difficult to implement in any other way., Figure 13.1 is a generic model of the process of constructing and using digital, signatures. All of the digital signature schemes discussed in this chapter have this, structure. Suppose that Bob wants to send a message to Alice. Although it is not, important that the message be kept secret, he wants Alice to be certain that the, message is indeed from him. For this purpose, Bob uses a secure hash function, such, as SHA-512, to generate a hash value for the message. That hash value, together, with Bob’s private key serves as input to a digital signature generation algorithm,, which produces a short block that functions as a digital signature. Bob sends the, message with the signature attached. When Alice receives the message plus signature, she (1) calculates a hash value for the message; (2) provides the hash value and, Bob’s public key as inputs to a digital signature verification algorithm. If the algorithm returns the result that the signature is valid, Alice is assured that the message, must have been signed by Bob. No one else has Bob’s private key and therefore no, one else could have created a signature that could be verified for this message with, Bob’s public key. In addition, it is impossible to alter the message without access to, Bob’s private key, so the message is authenticated both in terms of source and in, terms of data integrity., We begin this chapter with an overview of digital signatures. We then present the, Elgamal and Schnorr digital signature schemes, understanding of which makes it easier, to understand the NIST Digital Signature Algorithm (DSA). The chapter then covers the two other important standardized digital signature schemes: the Elliptic Curve, Digital Signature Algorithm (ECDSA) and the RSA Probabilistic Signature Scheme, (RSA-PSS).
Page 422 :
13.1 / DIGITAL SIGNATURES, , Bob, , Alice, , Message M, , Cryptographic, hash, function, , h, , Message M, , Bob’s, private, key, , Message M, , S, , Cryptographic, hash, function, Bob’s, public, key, , h, , Digital, signature, generation, algorithm, , Digital, signature, verification, algorithm, , S, , Return, signature, valid or not valid, , Bob’s, signature, for M, (a) Bob signs a message, , Figure 13.1, , 421, , (b) Alice verifies the signature, , Simplified Depiction of Essential Elements of Digital Signature Process, , 13.1 DIGITAL SIGNATURES, Properties, Message authentication protects two parties who exchange messages from any third, party. However, it does not protect the two parties against each other. Several forms, of dispute between the two parties are possible.
Page 423 :
422, , CHAPTER 13 / DIGITAL SIGNATURES, , For example, suppose that John sends an authenticated message to Mary,, using one of the schemes of Figure 12.1. Consider the following disputes that could, arise., 1. Mary may forge a different message and claim that it came from John. Mary, would simply have to create a message and append an authentication code, using the key that John and Mary share., 2. John can deny sending the message. Because it is possible for Mary to forge, a message, there is no way to prove that John did in fact send the message., Both scenarios are of legitimate concern. Here is an example of the first, scenario: An electronic funds transfer takes place, and the receiver increases the, amount of funds transferred and claims that the larger amount had arrived from, the sender. An example of the second scenario is that an electronic mail message, contains instructions to a stockbroker for a transaction that subsequently turns out, badly. The sender pretends that the message was never sent., In situations where there is not complete trust between sender and receiver,, something more than authentication is needed. The most attractive solution to, this problem is the digital signature. The digital signature must have the following, properties:, ■, ■, ■, , It must verify the author and the date and time of the signature., It must authenticate the contents at the time of the signature., It must be verifiable by third parties, to resolve disputes., , Thus, the digital signature function includes the authentication function., , Attacks and Forgeries, [GOLD88] lists the following types of attacks, in order of increasing severity. Here, A denotes the user whose signature method is being attacked, and C denotes the, attacker., ■, ■, ■, , ■, , ■, , Key-only attack: C only knows A’s public key., Known message attack: C is given access to a set of messages and their, signatures., Generic chosen message attack: C chooses a list of messages before attempting to breaks A’s signature scheme, independent of A’s public key. C then, obtains from A valid signatures for the chosen messages. The attack is generic,, because it does not depend on A’s public key; the same attack is used against, everyone., Directed chosen message attack: Similar to the generic attack, except that the, list of messages to be signed is chosen after C knows A’s public key but before, any signatures are seen., Adaptive chosen message attack: C is allowed to use A as an “oracle.” This, means that C may request from A signatures of messages that depend on, previously obtained message-signature pairs.
Page 424 :
13.1 / DIGITAL SIGNATURES, , 423, , [GOLD88] then defines success at breaking a signature scheme as an outcome, in which C can do any of the following with a non-negligible probability:, ■, ■, ■, ■, , Total break: C determines A’s private key., Universal forgery: C finds an efficient signing algorithm that provides an, equivalent way of constructing signatures on arbitrary messages., Selective forgery: C forges a signature for a particular message chosen by C., Existential forgery: C forges a signature for at least one message. C has, no control over the message. Consequently, this forgery may only be a minor, nuisance to A., , Digital Signature Requirements, On the basis of the properties and attacks just discussed, we can formulate the, following requirements for a digital signature., ■, ■, ■, ■, ■, , ■, , The signature must be a bit pattern that depends on the message being signed., The signature must use some information only known to the sender to prevent, both forgery and denial., It must be relatively easy to produce the digital signature., It must be relatively easy to recognize and verify the digital signature., It must be computationally infeasible to forge a digital signature, either by, constructing a new message for an existing digital signature or by constructing, a fraudulent digital signature for a given message., It must be practical to retain a copy of the digital signature in storage., , A secure hash function, embedded in a scheme such as that of Figure 13.1, provides, a basis for satisfying these requirements. However, care must be taken in the design, of the details of the scheme., , Direct Digital Signature, The term direct digital signature refers to a digital signature scheme that involves, only the communicating parties (source, destination). It is assumed that the destination knows the public key of the source., Confidentiality can be provided by encrypting the entire message plus, signature with a shared secret key (symmetric encryption). Note that it is important, to perform the signature function first and then an outer confidentiality function., In case of dispute, some third party must view the message and its signature. If the, signature is calculated on an encrypted message, then the third party also needs, access to the decryption key to read the original message. However, if the signature, is the inner operation, then the recipient can store the plaintext message and its, signature for later use in dispute resolution., The validity of the scheme just described depends on the security of the sender’s private key. If a sender later wishes to deny sending a particular message, the, sender can claim that the private key was lost or stolen and that someone else forged, his or her signature. Administrative controls relating to the security of private keys
Page 425 :
424, , CHAPTER 13 / DIGITAL SIGNATURES, , can be employed to thwart or at least weaken this ploy, but the threat is still there,, at least to some degree. One example is to require every signed message to include, a timestamp (date and time) and to require prompt reporting of compromised keys, to a central authority., Another threat is that a private key might actually be stolen from X at time T., The opponent can then send a message signed with X’s signature and stamped with, a time before or equal to T., The universally accepted technique for dealing with these threats is the use, of a digital certificate and certificate authorities. We defer a discussion of this topic, until Chapter 14, and focus in this chapter on digital signature algorithms., , 13.2 ELGAMAL DIGITAL SIGNATURE SCHEME, Before examining the NIST Digital Signature Algorithm, it will be helpful to understand the Elgamal and Schnorr signature schemes. Recall from Chapter 10, that the, Elgamal encryption scheme is designed to enable encryption by a user’s public key, with decryption by the user’s private key. The Elgamal signature scheme involves, the use of the private key for digital signature generation and the public key for, digital signature verification [ELGA84, ELGA85]., Before proceeding, we need a result from number theory. Recall from Chapter 2, that for a prime number q, if a is a primitive root of q, then, a, a2, c , aq - 1, are distinct (mod q). It can be shown that, if a is a primitive root of q, then, 1. For any integer m, am K 1 (mod q) if and only if m K 0 (mod q - 1)., 2. For any integers, i, j, ai K aj (mod q) if and only if i K j (mod q - 1)., As with Elgamal encryption, the global elements of Elgamal digital signature, are a prime number q and a, which is a primitive root of q. User A generates, a private/public key pair as follows., 1. Generate a random integer XA, such that 1 6 XA 6 q - 1., 2. Compute YA = aXA mod q., 3. A’s private key is XA; A’s pubic key is {q, a, YA}., To sign a message M, user A first computes the hash m = H(M), such that, m is an integer in the range 0 … m … q - 1. A then forms a digital signature as, follows., 1. Choose a random integer K such that 1 … K … q - 1 and gcd(K, q - 1) = 1., That is, K is relatively prime to q - 1., 2. Compute S1 = aK mod q. Note that this is the same as the computation of C1, for Elgamal encryption., 3. Compute K -1 mod (q - 1). That is, compute the inverse of K modulo q - 1., 4. Compute S2 = K -1(m - XAS1) mod (q - 1)., 5. The signature consists of the pair (S1, S2)., , Hiva-Network.Com
Page 426 :
13.3 / SCHNORR DIGITAL SIGNATURE SCHEME, , 425, , Any user B can verify the signature as follows., 1. Compute V1 = am mod q., 2. Compute V2 = (YA)S1(S1)S2 mod q., The signature is valid if V1 = V2. Let us demonstrate that this is so. Assume, that the equality is true. Then we have, am mod q = (YA)S1(S1)S2 mod q, am mod q = aXAS1aKS2 mod q, am - XAS1 mod q = aKS2 mod q, m - XAS1 K KS2 mod (q - 1), m - XAS1 K KK -1 (m - XAS1) mod (q - 1), , assume V1 = V2, substituting for YA and S1, rearranging terms, property of primitive roots, substituting for S2, , For example, let us start with the prime field GF(19); that is, q = 19. It has, primitive roots {2, 3, 10, 13, 14, 15}, as shown in Table 2.7. We choose a = 10., Alice generates a key pair as follows:, 1. Alice chooses XA = 16., 2. Then YA = aXA mod q = a16 mod 19 = 4., 3. Alice’s private key is 16; Alice’s pubic key is {q, a, YA} = {19, 10, 4}., Suppose Alice wants to sign a message with hash value m = 14., 1., 2., 3., 4., , Alice chooses K = 5, which is relatively prime to q - 1 = 18., S1 = aK mod q = 105 mod 19 = 3 (see Table 2.7)., K -1 mod (q - 1) = 5-1 mod 18 = 11., S2 = K -1 (m - XAS1) mod (q - 1) = 11 (14 - (16)(3)) mod 18 = -374, mod 18 = 4., Bob can verify the signature as follows., , 1. V1 = am mod q = 1014 mod 19 = 16., 2. V2 = (YA)S1(S1)S2 mod q = (43)(34) mod 19 = 5184 mod 19 = 16., Thus, the signature is valid because V1 = V2., , 13.3 SCHNORR DIGITAL SIGNATURE SCHEME, As with the Elgamal digital signature scheme, the Schnorr signature scheme is, based on discrete logarithms [SCHN89, SCHN91]. The Schnorr scheme minimizes, the message-dependent amount of computation required to generate a signature., The main work for signature generation does not depend on the message and can, be done during the idle time of the processor. The message-dependent part of the, signature generation requires multiplying a 2n-bit integer with an n-bit integer., The scheme is based on using a prime modulus p, with p - 1 having a prime, factor q of appropriate size; that is, p - 1 K 0 (mod q). Typically, we use p ≈ 21024, and q ≈ 2160. Thus, p is a 1024-bit number, and q is a 160-bit number, which is also, the length of the SHA-1 hash value.
Page 427 :
426, , CHAPTER 13 / DIGITAL SIGNATURES, , The first part of this scheme is the generation of a private/public key pair,, which consists of the following steps., 1. Choose primes p and q, such that q is a prime factor of p - 1., 2. Choose an integer a, such that aq = 1 mod p. The values a, p, and q comprise a, global public key that can be common to a group of users., 3. Choose a random integer s with 0 6 s 6 q. This is the user’s private key., 4. Calculate v = a-s mod p. This is the user’s public key., A user with private key s and public key v generates a signature as follows., 1. Choose a random integer r with 0 6 r 6 q and compute x = ar mod p. This, computation is a preprocessing stage independent of the message M to be, signed., 2. Concatenate the message with x and hash the result to compute the value e:, e = H(M } x), 3. Compute y = (r + se) mod q. The signature consists of the pair (e, y)., Any other user can verify the signature as follows., 1. Compute x′ = ayve mod p., 2. Verify that e = H (M } x′)., To see that the verification works, observe that, x′ K ayve K aya-se K ay - se K ar K x (mod p), Hence, H (M } x′) = H (M } x)., , 13.4 NIST DIGITAL SIGNATURE ALGORITHM, The National Institute of Standards and Technology (NIST) has published, Federal Information Processing Standard FIPS 186, known as the Digital, Signature Algorithm (DSA). The DSA makes use of the Secure Hash Algorithm, (SHA) described in Chapter 12. The DSA was originally proposed in 1991 and, revised in 1993 in response to public feedback concerning the security of the, scheme. There was a further minor revision in 1996. In 2000, an expanded version, of the standard was issued as FIPS 186-2, subsequently updated to FIPS 186-3 in, 2009, and FIPS 186-4 in 2013. This latest version also incorporates digital signature algorithms based on RSA and on elliptic curve cryptography. In this section,, we discuss DSA., , The DSA Approach, The DSA uses an algorithm that is designed to provide only the digital signature function. Unlike RSA, it cannot be used for encryption or key exchange., Nevertheless, it is a public-key technique.
Page 428 :
13.4 / NIST DIGITAL SIGNATURE ALGORITHM, ||, , M, , H, , M, , PRa, H, , PUa, , E, , 427, , Compare, , D, , E(PRa, H(M)], , (a) RSA approach, ||, , M, , M, s, r, , PUG PRa, H, , Sig, , H, PUG PUa, , Ver, , Compare, , k, , (b) DSA approach, Figure 13.2 Two Approaches to Digital Signatures, , Figure 13.2 contrasts the DSA approach for generating digital signatures to, that used with RSA. In the RSA approach, the message to be signed is input to a, hash function that produces a secure hash code of fixed length. This hash code is, then encrypted using the sender’s private key to form the signature. Both the message and the signature are then transmitted. The recipient takes the message and, produces a hash code. The recipient also decrypts the signature using the sender’s, public key. If the calculated hash code matches the decrypted signature, the signature is accepted as valid. Because only the sender knows the private key, only the, sender could have produced a valid signature., The DSA approach also makes use of a hash function. The hash code is provided as input to a signature function along with a random number k generated for, this particular signature. The signature function also depends on the sender’s private, key (PRa) and a set of parameters known to a group of communicating principals., We can consider this set to constitute a global public key (PUG).1 The result is a, signature consisting of two components, labeled s and r., At the receiving end, the hash code of the incoming message is generated. The, hash code and the signature are inputs to a verification function. The verification, function also depends on the global public key as well as the sender’s public key, (PUa), which is paired with the sender’s private key. The output of the verification, function is a value that is equal to the signature component r if the signature is valid., The signature function is such that only the sender, with knowledge of the private, key, could have produced the valid signature., We turn now to the details of the algorithm., , 1, , It is also possible to allow these additional parameters to vary with each user so that they are a part of, a user’s public key. In practice, it is more likely that a global public key will be used that is separate from, each user’s public key.
Page 429 :
428, , CHAPTER 13 / DIGITAL SIGNATURES, Global Public-Key Components, , p, , q, , L-1, , L, , prime number where 2, 6 p 6 2, for 512 … L … 1024 and L a multiple of 64;, i.e., bit length L between 512 and 1024 bits, in increments of 64 bits, , Signing, r, , = (g mod p) mod q, , s, , = [k -1 (H(M) + xr)] mod q, , k, , Signature = (r, s), , prime divisor of (p - 1), where 2N - 1 6 q 6 2N, i.e., bit length of N bits, , g = h(p - 1)/q is an exponent mod p,, where h is any integer with 1 6 h 6 (p - 1), such that h(p - 1)/q mod p 7 1, , Verifying, w = (s′), , -1, , mod q, , u 1 = [H(M′)w] mod q, u 2 = (r′)w mod q, , User’s Private Key, x, , random or pseudorandom integer with 0 6 x 6 q, , User’s Public Key, y = gx mod p, , v = [(g u1yu2) mod p] mod q, TEST: v = r′, M, , = message to be signed, , H(M), , = hash of M using SHA-1, , M′, r′, s′ = received versions of M, r, s, User’s Per-Message Secret Number, k, , random or pseudorandom integer with 0 6 k 6 q, , Figure 13.3 The Digital Signature Algorithm (DSA), , The Digital Signature Algorithm, DSA is based on the difficulty of computing discrete logarithms (see Chapter 2), and is based on schemes originally presented by Elgamal [ELGA85] and Schnorr, [SCHN91]., Figure 13.3 summarizes the algorithm. There are three parameters that are, public and can be common to a group of users. An N-bit prime number q is chosen., Next, a prime number p is selected with a length between 512 and 1024 bits such, that q divides (p - 1). Finally, g is chosen to be of the form h(p - 1)/q mod p, where h, is an integer between 1 and (p - 1) with the restriction that g must be greater, than 1.2 Thus, the global public-key components of DSA are the same as in the, Schnorr signature scheme., With these parameters in hand, each user selects a private key and generates, a public key. The private key x must be a number from 1 to (q - 1) and should, be chosen randomly or pseudorandomly. The public key is calculated from the, private key as y = gx mod p. The calculation of y given x is relatively straightforward. However, given the public key y, it is believed to be computationally, infeasible to determine x, which is the discrete logarithm of y to the base g, mod p, (see Chapter 2)., , 2, , In number-theoretic terms, g is of order q mod p; see Chapter 2.
Page 430 :
13.4 / NIST DIGITAL SIGNATURE ALGORITHM, , 429, , The signature of a message M consists of the pair of numbers r and s, which are, functions of the public key components (p, q, g), the user’s private key (x), the hash, code of the message H(M), and an additional integer k that should be generated, randomly or pseudorandomly and be unique for each signing., Let M, r′, and s′ be the received versions of M, r, and s, respectively., Verification is performed using the formulas shown in Figure 13.3. The receiver, generates a quantity v that is a function of the public key components, the sender’s, public key, the hash code of the incoming message, and the received versions of r, and s. If this quantity matches the r component of the signature, then the signature, is validated., Figure 13.4 depicts the functions of signing and verifying., , M, , p, , k, , k, , q, , g, , M, r = (gk mod p) mod q, q, , k, , H, , s = [k–1 (H(M) + xr)] mod q, , r, s, , H(M), x, , x, (a) Signing, , y, , H, , H(Mœ), , g, , u1 = [H(Mœ)w)] mod q, u2 = (rœ)w mod q, v = [(gu1yu2) mod p] mod q, , Mœ, w, , rœ, , v, rœ signature, verification, rœ = v?, , q, , rœ, sœ, , q, , w = (sœ)–1 mod q, , (b) Verifying, , Figure 13.4 DSA Signing and Verifying
Page 431 :
430, , CHAPTER 13 / DIGITAL SIGNATURES, , The structure of the algorithm, as revealed in Figure 13.4, is quite interesting., Note that the test at the end is on the value r, which does not depend on the message at all. Instead, r is a function of k and the three global public-key components., The multiplicative inverse of k (mod q) is passed to a function that also has as inputs, the message hash code and the user’s private key. The structure of this function is, such that the receiver can recover r using the incoming message and signature, the, public key of the user, and the global public key. It is certainly not obvious from, Figure 13.3 or Figure 13.4 that such a scheme would work. A proof is provided in, Appendix K., Given the difficulty of taking discrete logarithms, it is infeasible for an, opponent to recover k from r or to recover x from s., Another point worth noting is that the only computationally demanding, task in signature generation is the exponential calculation gk mod p. Because this, value does not depend on the message to be signed, it can be computed ahead of, time. Indeed, a user could precalculate a number of values of r to be used to sign, documents as needed. The only other somewhat demanding task is the determination of a multiplicative inverse, k -1. Again, a number of these values can be, precalculated., , 13.5 ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM, As was mentioned, the 2009 version of FIPS 186 includes a new digital signature, technique based on elliptic curve cryptography, known as the Elliptic Curve Digital, Signature Algorithm (ECDSA). ECDSA is enjoying increasing acceptance due, to the efficiency advantage of elliptic curve cryptography, which yields security, comparable to that of other schemes with a smaller key bit length., First we give a brief overview of the process involved in ECDSA. In essence,, four elements are involved., 1. All those participating in the digital signature scheme use the same global domain, parameters, which define an elliptic curve and a point of origin on the curve., 2. A signer must first generate a public, private key pair. For the private key, the, signer selects a random or pseudorandom number. Using that random number, and the point of origin, the signer computes another point on the elliptic curve., This is the signer’s public key., 3. A hash value is generated for the message to be signed. Using the private, key, the domain parameters, and the hash value, a signature is generated. The, signature consists of two integers, r and s., 4. To verify the signature, the verifier uses as input the signer’s public key, the, domain parameters, and the integer s. The output is a value v that is compared, to r. The signature is verified if v = r., Let us examine each of these four elements in turn.
Page 432 :
13.5 / ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM, , 431, , Global Domain Parameters, Recall from Chapter 10 that two families of elliptic curves are used in cryptographic, applications: prime curves over Z p and binary curves over GF(2m). For ECDSA,, prime curves are used. The global domain parameters for ECDSA are the following:, q, a, b, , a prime number, integers that specify the elliptic curve equation defined over Z q with the, equation y2 = x3 + ax + b, , G, , a base point represented by G = (xg, yg) on the elliptic curve equation, , n, , order of point G; that is, n is the smallest positive integer such that, nG = O. This is also the number of points on the curve., , Key Generation, Each signer must generate a pair of keys, one private and one public. The signer,, let us call him Bob, generates the two keys using the following steps:, 1. Select a random integer d, d ∈ [1, n - 1], 2. Compute Q = dG. This is a point in E q(a, b), 3. Bob’s public key is Q and private key is d., , Digital Signature Generation and Authentication, With the public domain parameters and a private key in hand, Bob generates, a digital signature of 320 bytes for message m using the following steps:, 1., 2., 3., 4., 5., 6., , Select a random or pseudorandom integer k, k ∈ [1, n - 1], Compute point P = (x, y) = kG and r = x mod n. If r = 0 then goto step 1, Compute t = k -1 mod n, Compute e = H(m), where H is one of the SHA-2 or SHA-3 hash functions., Compute s = k -1(e + dr) mod n. If s = O then goto step 1, The signature of message m is the pair (r, s)., , Alice knows the public domain parameters and Bob’s public key. Alice is, presented with Bob’s message and digital signature and verifies the signature using, the following steps:, 1., 2., 3., 4., 5., 6., 7., , Verify that r and s are integers in the range 1 through n - 1, Using SHA, compute the 160-bit hash value e = H(m), Compute w = s -1 mod n, Compute u 1 = ew and u 2 = rw, Compute the point X = (x1, y1) = u 1G + u 2Q, If X = O, reject the signature else compute v = x1 mod n, Accept Bob’s signature if and only if v = r
Page 433 :
432, , CHAPTER 13 / DIGITAL SIGNATURES, , Bob, , Alice, , q, a, b, G, n, are shared, global variables, Generate private, key d. Public, key Q = dG, , Q, r, s, , Generate k, (x, y) = kG, r = x mod n, Yes, , No, , Yes, e = H(m), w = s–1 mod n, u1 = ew, u2 = rw, X = (x1, x2) = u1G + u2Q, , r = 0?, No, , e = H(m), s = k–1 (e + dr) mod n, , Yes, , r, s integers, in range, [1, n–1]?, , X = O?, , Yes, , No, s = 0?, , v = x1 mod n, , No, Signature of m, is r, s, , Figure 13.5, , Accept Yes, signature, , v = r?, , No, , Reject, signature, , ECDSA Signing and Verifying, , Figure 13.5 illustrates the signature authentication process. We can verify that, this process is valid as follows. If the message received by Alice is in fact signed by, Bob, then, s = k -1(e + dr) mod n, Then, k = s -1(e + dr) mod n, k = (s -1e + s -1dr) mod n, k = (we + wdr) mod n, k = (u 1 + u 2d) mod n, Now consider that, u 1G + u 2Q = u 1G + u 2dG = (u 1 + u 2d)G = kG
Page 434 :
13.6 / RSA-PSS DIGITAL SIGNATURE ALGORITHM, , 433, , In step 6 of the verification process, we have v = x1 mod n, where point, X = (x1, y1) = u 1G + u 2Q. Thus we see that v = r since r = x mod n and x is the x, coordinate of the point kG and we have already seen that u 1G + u 2Q = kG., , 13.6 RSA-PSS DIGITAL SIGNATURE ALGORITHM, In addition to the NIST Digital Signature Algorithm and ECDSA, the 2009 version, of FIPS 186 also includes several techniques based on RSA, all of which were developed by RSA Laboratories and are in wide use. A worked-out example, using RSA,, is available at this book’s Web site., In this section, we discuss the RSA Probabilistic Signature Scheme (RSA-PSS),, which is the latest of the RSA schemes and the one that RSA Laboratories recommends as the most secure of the RSA schemes., Because the RSA-based schemes are widely deployed in many applications,, including financial applications, there has been great interest in demonstrating that, such schemes are secure. The three main RSA signature schemes differ mainly in, the padding format the signature generation operation employs to embed the hash, value into a message representative, and in how the signature verification operation determines that the hash value and the message representative are consistent., For all of the schemes developed prior to PSS, it has not been possible to develop, a mathematical proof that the signature scheme is as secure as the underlying RSA, encryption/decryption primitive [KALI01]. The PSS approach was first proposed by, Bellare and Rogaway [BELL96c, BELL98]. This approach, unlike the other RSAbased schemes, introduces a randomization process that enables the security of the, method to be shown to be closely related to the security of the RSA algorithm itself., This makes RSA-PSS more desirable as the choice for RSA-based digital signature, applications., , Mask Generation Function, Before explaining the RSA-PSS operation, we need to describe the mask generation function (MGF) used as a building block. MGF(X, maskLen) is a pseudorandom function that has as input parameters a bit string X of any length and the, desired length L in octets of the output. MGFs are typically based on a secure, cryptographic hash function such as SHA-1. An MGF based on a hash function is, intended to be a cryptographically secure way of generating a message digest, or, hash, of variable length based on an underlying cryptographic hash function that, produces a fixed-length output., The MGF function used in the current specification for RSA-PSS is MGF1,, with the following parameters:, Options, , Hash, , hash function with output hLen octets, , Input, , X, , octet string to be masked, , maskLen, , length in octets of the mask, , mask, , an octet string of length maskLen, , Output, , Hiva-Network.Com
Page 435 :
434, , CHAPTER 13 / DIGITAL SIGNATURES, , MGF1 is defined as follows:, 1. Initialize variables., T = empty string, k = < maskLen/hLen = - 1, 2. Calculate intermediate values., for counter = 0 to k, Represent counter as a 32-bit string C, T = T } Hash(X } C), 3. Output results., mask = the leading maskLen octets of T, In essence, MGF1 does the following. If the length of the desired output is, equal to the length of the hash value (maskLen = hLen), then the output is the, hash of the input value X concatenated with a 32-bit counter value of 0. If maskLen, is greater than hLen, the MGF1 keeps iterating by hashing X concatenated with the, counter and appending that to the current string T. So that the output is, Hash (X } 0) } Hash(X } 1) } c } Hash(X } k), This is repeated until the length of T is greater than or equal to maskLen, at which, point the output is the first maskLen octets of T., , The Signing Operation, MESSAGE ENCODING The first stage in generating an RSA-PSS signature of a message, M is to generate from M a fixed-length message digest, called an encoded message, (EM). Figure 13.6 illustrates this process. We define the following parameters and, functions:, Options, , Input, , Output, , Hash, , hash function with output hLen octets. The current, preferred alternative is SHA-1, which produces a 20-octet, hash value., , MGF, , mask generation function. The current specification calls, for MGF1., , sLen, , length in octets of the salt. Typically sLen = hLen, which, for the current version is 20 octets., , M, , message to be encoded for signing., , emBits, , This value is one less than the length in bits of the RSA, modulus n., , EM, , encoded message. This is the message digest that will be, encrypted to form the digital signature., , Parameters emLen, padding 1, , length of EM in octets = < emBits/8 = ., hexadecimal string 00 00 00 00 00 00 00 00; that is, a string, of 64 zero bits.
Page 436 :
13.6 / RSA-PSS DIGITAL SIGNATURE ALGORITHM, , 435, , M, , Hash, , Mœ =, , DB =, , padding2, , padding1, , mHash, , salt, , salt, , Hash, , MGF, , EM =, , Figure 13.6, , maskedDB, , H, , bc, , RSA-PSS Encoding, , padding 2, , hexadecimal string of 00 octets with a length, (emLen - sLen - hLen - 2) octets, followed by the, hexadecimal octet with value 01., , salt, , a pseudorandom number., , bc, , the hexadecimal value BC., , The encoding process consists of the following steps., 1. Generate the hash value of M: mHash = Hash(M), 2. Generate a pseudorandom octet string salt and form block M′ = padding 1 }, mHash } salt, 3. Generate the hash value of M′: H = Hash(M′), 4. Form data block DB = padding 2 } salt, 5. Calculate the MGF value of H: dbMask = MGF(H, emLen - hLen - 1), 6. Calculate maskedDB = DB ⊕ dbMsk, 7. Set the leftmost 8emLen - emBits bits of the leftmost octet in maskedDB to 0, 8. EM = maskedDB } H } 0xbc, We make several comments about the complex nature of this message, digest algorithm. All of the RSA-based standardized digital signature schemes, involve appending one or more constants (e.g., padding 1 and padding 2) in the, process of forming the message digest. The objective is to make it more difficult, for an adversary to find another message that maps to the same message digest
Page 437 :
436, , CHAPTER 13 / DIGITAL SIGNATURES, , as a given message or to find two messages that map to the same message digest., RSA-PSS also incorporates a pseudorandom number, namely the salt. Because the, salt changes with every use, signing the same message twice using the same private, key will yield two different signatures. This is an added measure of security., FORMING THE SIGNATURE We now show how the signature is formed by a signer, with private key {d, n} and public key {e, n} (see Figure 9.5). Treat the octet string, EM as an unsigned, nonnegative binary integer m. The signature s is formed by, encrypting m as follows:, s = md mod n, Let k be the length in octets of the RSA modulus n. For example if the key size, for RSA is 2048 bits, then k = 2048/8 = 256. Then convert the signature value s, into the octet string S of length k octets., , Signature Verification, DECRYPTION For signature verification, treat the signature S as an unsigned,, nonnegative binary integer s. The message digest m is recovered by decrypting s as, follows:, m = se mod n, Then, convert the message representative m to an encoded message EM of, length emLen = <(modBits - 1)/8 = octets, where modBits is the length in bits of, the RSA modulus n., EM VERIFICATION EM verification can be described as follows:, Options, , Input, , Hash, , hash function with output hLen octets., , MGF, , mask generation function., , sLen, , length in octets of the salt., , M, , message to be verified., , EM, , the octet string representing the decrypted signature,, with length emLen = < emBits/8 = ., , emBits, , This value is one less than the length in bits of the RSA, modulus n., , Parameters padding 1, padding 2, , hexadecimal string 00 00 00 00 00 00 00 00; that is,, a string of 64 zero bits., hexadecimal string of 00 octets with a length, (emLen - sLen - hLen - 2) octets, followed by the, hexadecimal octet with value 01., , 1. Generate the hash value of M: mHash = Hash(M), 2. If emLen 6 hLen + sLen + 2, output “inconsistent” and stop, 3. If the rightmost octet of EM does not have hexadecimal value BC, output, “inconsistent” and stop
Page 438 :
13.6 / RSA-PSS DIGITAL SIGNATURE ALGORITHM, , 437, , 4. Let maskedDB be the leftmost emLen - hLen - 1 octets of EM, and let H be, the next hLen octets, 5. If the leftmost 8emLen - emBits bits of the leftmost octet in maskedDB are, not all equal to zero, output “inconsistent” and stop, 6. Calculate dbMask = MGF (H, emLen - hLen - 1), 7. Calculate DB = maskedDB ⊕ dbMsk, 8. Set the leftmost 8emLen - emBits bits of the leftmost octet in DB to zero, 9. If the leftmost (emLen - hLen - sLen - 1) octets of DB are not equal to, padding 2, output “inconsistent” and stop, 10. Let salt be the last sLen octets of DB, 11. Form block M′ = padding 1 } mHash } salt, 12. Generate the hash value of M′: H′ = Hash(M′), 13. If H = H′, output “consistent.” Otherwise, output “inconsistent”, Figure 13.7 illustrates the process. The shaded boxes labeled H and H′ correspond, respectively, to the value contained in the decrypted signature and the, value generated from the message M associated with the signature. The remaining, three shaded areas contain values generated from the decrypted signature and compared to known constants. We can now see more clearly the different roles played, by the constants and the pseudorandom value salt, all of which are embedded in the, , M, , Hash, , EM =, , H, , maskedDB, , dbMask, , DB =, , padding1, , salt, , mHash, , Hash, , Hœ, , Figure 13.7, , MGF, , RSA-PSS EM Verification, , salt, , = Mœ
Page 439 :
438, , CHAPTER 13 / DIGITAL SIGNATURES, , EM generated by the signer. The constants are known to the verifier, so that the, computed constants can be compared to the known constants as an additional check, that the signature is valid (in addition to comparing H and H′). The salt results in a, different signature every time a given message is signed with the same private key., The verifier does not know the value of the salt and does not attempt a comparison., Thus, the salt plays a similar role to the pseudorandom variable k in the NIST DSA, and in ECDSA. In both of those schemes, k is a pseudorandom number generated by, the signer, resulting in different signatures from multiple signings of the same message with the same private key. A verifier does not and need not know the value of k., , 13.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, digital signature, Digital Signature Algorithm, (DSA), direct digital signature, , Elgamal digital signature, Elliptic Curve Digital, Signature Algorithm, (ECDSA), , Schnorr digital signature, timestamp, , Review Questions, 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, , List two disputes that can arise in the context of message authentication., What are the properties a digital signature should have?, What requirements should a digital signature scheme satisfy?, What is the difference between direct and arbitrated digital signature?, In what order should the signature function and the confidentiality function be, applied to a message, and why?, What are some threats associated with a direct digital signature scheme?, , Problems, 13.1, , Dr. Watson patiently waited until Sherlock Holmes finished. “Some interesting problem to solve, Holmes?” he asked when Holmes finally logged out., “Oh, not exactly. I merely checked my email and then made a couple of, network experiments instead of my usual chemical ones. I have only one client now, and I have already solved his problem. If I remember correctly, you once mentioned, cryptology among your other hobbies, so it may interest you.”, “Well, I am only an amateur cryptologist, Holmes. But of course I am interested, in the problem. What is it about?”, “My client is Mr. Hosgrave, director of a small but progressive bank. The bank, is fully computerized and of course uses network communications extensively. The, bank already uses RSA to protect its data and to digitally sign documents that are, communicated. Now the bank wants to introduce some changes in its procedures; in, particular, it needs to digitally sign some documents by two signatories., , 1. The first signatory prepares the document, forms its signature, and passes the, document to the second signatory.
Page 440 :
13.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 439, , 2. The second signatory as a first step must verify that the document was really signed, , 13.2, 13.3, 13.4, , 13.5, , 13.6, , by the first signatory. She then incorporates her signature into the document’s signature so that the recipient, as well as any member of the public, may verify that the, document was indeed signed by both signatories. In addition, only the second signatory has to be able to verify the document’s signature after the first step; that is, the, recipient (or any member of the public) should be able to verify only the complete, document with signatures of both signatories, but not the document in its intermediate form where only one signatory has signed it. Moreover, the bank would like to, make use of its existing modules that support RSA-style digital signatures.”, “Hm, I understand how RSA can be used to digitally sign documents by one signatory,, Holmes. I guess you have solved the problem of Mr. Hosgrave by appropriate generalization of RSA digital signatures.”, “Exactly, Watson,” nodded Sherlock Holmes. “Originally, the RSA digital signature was formed by encrypting the document by the signatory’s private decryption, key ‘d’, and the signature could be verified by anyone through its decryption using, publicly known encryption key ‘e’. One can verify that the signature S was formed, by the person who knows d, which is supposed to be the only signatory. Now the, problem of Mr. Hosgrave can be solved in the same way by slight generalization of, the process, that is …”, Finish the explanation., DSA specifies that if the signature generation process results in a value of s = 0,, a new value of k should be generated and the signature should be recalculated. Why?, What happens if a k value used in creating a DSA signature is compromised?, The DSA document includes a recommended algorithm for testing a number for, primality., 1. [Choose w] Let w be a random odd integer. Then (w - 1) is even and can be, expressed in the form 2am with m odd. That is, 2a is the largest power of 2 that, divides (w - 1)., 2. [Generate b] Let b be a random integer in the range 1 6 b 6 w., 3. [Exponentiate] Set j = 0 and z = bm mod w., 4. [Done?] If j = 0 and z = 1, or if z = w - 1, then w passes the test and may be, prime; go to step 8., 5. [Terminate?] If j 7 0 and z = 1, then w is not prime; terminate algorithm for this w., 6. [Increase j] Set j = j + 1. If j 6 a, set z = z2 mod w and go to step 4., 7. [Terminate] w is not prime; terminate algorithm for this w., 8. [Test again?] If enough random values of b have been tested, then accept w as, prime and terminate algorithm; otherwise, go to step 2., a. Explain how the algorithm works., b. Show that it is equivalent to the Miller–Rabin test described in Chapter 2., With DSA, because the value of k is generated for each signature, even if the same, message is signed twice on different occasions, the signatures will differ. This is not, true of RSA signatures. What is the practical implication of this difference?, Consider the problem of creating domain parameters for DSA. Suppose we have, already found primes p and q such that q (p - 1). Now we need to find g ∈ Zp with, g of order q mod p. Consider the following two algorithms:, Algorithm 1, repeat, select g ∈ Zp, h d gq mod p, until (h = 1 and g ≠ 1), return g, , Algorithm 2, repeat, select h ∈ Zp, g d h(p - 1)/q mod p, until (g ≠ 1), return g
Page 441 :
440, , CHAPTER 13 / DIGITAL SIGNATURES, a. What happens in Algorithm 1 if ord(q) = q is chosen?, b. hat happens in Algorithm 2 if ord(q) = q is chosen?, c. Suppose p = 64891 and q = 421. How many loop iterations do you expect, Algorithm 1 to make before it finds a generator?, d. If p is 512 bits and q is 128 bits, would you recommend using Algorithm 1 to find g?, Explain., e. Suppose p = 64891 and q = 421. What is the probability that Algorithm 2, computes a generator in its very first loop iteration? (If it is helpful, you may use, the fact that a (dn)c(d) = n when answering this question.), 13.7, , It is tempting to try to develop a variation on Diffie–Hellman that could be used as, a digital signature. Here is one that is simpler than DSA and that does not require a, secret random number in addition to the private key., q, , prime number, , a, , a 6 q and a is primitive root of q, , Private key:, , X, , X6 q, , Public key:, , Y = aX mod q mod q, , Public elements:, , 13.8, , To sign a message M, compute h = H(M), which is the hash code of the message., We require that gcd(h, q - 1) = 1. If not, append the hash to the message and calculate a new hash. Continue this process until a hash code is produced that is relatively, prime to (q - 1). Then calculate Z to satisfy Z K X * h(mod q - 1). The signature of the message is s = aZ. To verify the signature, a user compute t such that, t * h = 1 mod (q - 1) and verifies Y = s t mod q., a. Show that the scheme is unacceptable by describing a simple technique for forging, a user’s signature on an arbitrary message., b. Show that the scheme is unacceptable by describing a simple technique for forging, a user’s signature on an arbitrary message., Assume a technique for a digital signature scheme using a cryptographic one-way, hash function (H) as follows. To sign an n-bit message, the sender randomly generates in advance 2n 64-bit cryptographic keys:, k1, k2, c , kn k1′, k2′, c , kn′, which are kept private. The sender generates the following two sets of validation, parameters which are made public., v1, v2, c , vn and v1′, v2′, c , vn′, where, vi = H(ki ‘0), vi′ = H(ki′‘1), The user sends the appropriate ki or Kiœ according to whether Mi is 0 or 1 respectively., For example, if the first 3-bits of the message are 011, then the first three keys of the, signature are k1, k2œ, k3œ., a. How does the receiver validate the message?, b. Is the technique secure?, c. How many times can the same set of secret keys be safely used for different messages?, d. What, if any, practical problems does this scheme present?
Page 442 :
PART FIVE: MUTUAL TRUST, CHAPTER, , Key Management, and Distribution, 14.1 Symmetric Key Distribution Using Symmetric Encryption, A Key Distribution Scenario, Hierarchical Key Control, Session Key Lifetime, A Transparent Key Control Scheme, Decentralized Key Control, Controlling Key Usage, 14.2 Symmetric Key Distribution Using Asymmetric Encryption, Simple Secret Key Distribution, Secret Key Distribution with Confidentiality and Authentication, A Hybrid Scheme, 14.3 Distribution of Public Keys, Public Announcement of Public Keys, Publicly Available Directory, Public-Key Authority, Public-Key Certificates, 14.4 X.509 Certificates, Certificates, X.509 Version 3, 14.5 Public-Key Infrastructure, PKIX Management Functions, PKIX Management Protocols, 14.6 Key Terms, Review Questions, and Problems, , 441
Page 443 :
442, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Discuss the concept of a key hierarchy., ◆ Understand the issues involved in using asymmetric encryption to distribute, symmetric keys., ◆ Present an overview of approaches to public-key distribution and analyze, the risks involved in various approaches., ◆ List and explain the elements in an X.509 certificate., ◆ Present an overview of public-key infrastructure concepts., , The topics of cryptographic key management and cryptographic key distribution are, complex, involving cryptographic, protocol, and management considerations. The purpose of this chapter is to give the reader a feel for the issues involved and a broad survey of the various aspects of key management and distribution. For more information,, the place to start is the three-volume NIST SP 800-57, followed by the recommended, readings listed at the end of this chapter., , 14.1 SYMMETRIC KEY DISTRIBUTION USING, SYMMETRIC ENCRYPTION, For symmetric encryption to work, the two parties to an exchange must share the, same key, and that key must be protected from access by others. Furthermore, frequent key changes are usually desirable to limit the amount of data compromised, if an attacker learns the key. Therefore, the strength of any cryptographic system, rests with the key distribution technique, a term that refers to the means of delivering, a key to two parties who wish to exchange data without allowing others to see the, key. For two parties A and B, key distribution can be achieved in a number of ways,, as follows:, 1. A can select a key and physically deliver it to B., 2. A third party can select the key and physically deliver it to A and B., 3. If A and B have previously and recently used a key, one party can transmit the, new key to the other, encrypted using the old key., 4. If A and B each has an encrypted connection to a third party C, C can deliver, a key on the encrypted links to A and B., Options 1 and 2 call for manual delivery of a key. For link encryption, this, is a reasonable requirement, because each link encryption device is going to be, exchanging data only with its partner on the other end of the link. However, for, end-to-end encryption over a network, manual delivery is awkward. In a distributed, system, any given host or terminal may need to engage in exchanges with many other, , Hiva-Network.Com
Page 444 :
14.1 / SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION, , 443, , 109, , Number of keys, , 108, , 107, , 106, , 5, , 6, , 7 8 9, , 103, , 2, , 3, , 4, , 5, , 6, , 7 8 9, , 104, , 2, , 3, , 4, , 5, , 6, , 7 8 9, , 105, , Number of endpoints, , Figure 14.1 Number of Keys Required to Support Arbitrary Connections between, Endpoints, , hosts and terminals over time. Thus, each device needs a number of keys supplied, dynamically. The problem is especially difficult in a wide-area distributed system., The scale of the problem depends on the number of communicating pairs that, must be supported. If end-to-end encryption is done at a network or IP level, then a, key is needed for each pair of hosts on the network that wish to communicate. Thus,, if there are N hosts, the number of required keys is [N(N - 1)]/2. If encryption is, done at the application level, then a key is needed for every pair of users or processes that require communication. Thus, a network may have hundreds of hosts, but thousands of users and processes. Figure 14.1 illustrates the magnitude of the, key distribution task for end-to-end encryption.1 A network using node-level, encryption with 1000 nodes would conceivably need to distribute as many as half a, million keys. If that same network supported 10,000 applications, then as many as, 50 million keys may be required for application-level encryption., Returning to our list, option 3 is a possibility for either link encryption or, end-to-end encryption, but if an attacker ever succeeds in gaining access to one key,, then all subsequent keys will be revealed. Furthermore, the initial distribution of, potentially millions of keys still must be made., 1, Note that this figure uses a log-log scale, so that a linear graph indicates exponential growth. A basic, review of log scales is in the math refresher document at the Computer Science Student Resource Site at, WilliamStallings.com/StudentSupport.html.
Page 445 :
444, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , Data, , Cryptographic, protection, , Session keys, , Cryptographic, protection, , Master keys, , Non-cryptographic, protection, , Figure 14.2 The Use of a Key Hierarchy, , For end-to-end encryption, some variation on option 4 has been widely, adopted. In this scheme, a key distribution center is responsible for distributing, keys to pairs of users (hosts, processes, applications) as needed. Each user must, share a unique key with the key distribution center for purposes of key distribution., The use of a key distribution center is based on the use of a hierarchy of keys., At a minimum, two levels of keys are used (Figure 14.2). Communication between, end systems is encrypted using a temporary key, often referred to as a session key., Typically, the session key is used for the duration of a logical connection, such as a, frame relay connection or transport connection, and then discarded. Each session, key is obtained from the key distribution center over the same networking facilities used for end-user communication. Accordingly, session keys are transmitted in, encrypted form, using a master key that is shared by the key distribution center and, an end system or user., For each end system or user, there is a unique master key that it shares with, the key distribution center. Of course, these master keys must be securely distributed in some fashion. However, the scale of the problem is vastly reduced. If there, are N entities that wish to communicate in pairs, then, as was mentioned, as many, as [N(N - 1)]/2 session keys are needed at any one time. However, only N master, keys are required, one for each entity. Thus, master keys can be distributed in some, non-cryptographic way, such as physical delivery., , A Key Distribution Scenario, The key distribution concept can be deployed in a number of ways. A typical, scenario is illustrated in Figure 14.3, which is based on a figure in [POPE79]. The scenario assumes that each user shares a unique master key with the key distribution, center (KDC)., Let us assume that user A wishes to establish a logical connection with B and, requires a one-time session key to protect the data transmitted over the connection.
Page 446 :
14.1 / SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION, Key Distribution, Center (KDC), , Initiator A, , 445, , Responder B, , (1) IDA || IDB || N1, , Key, distribution, steps, , (2) E(Ka, [Ks || IDA || IDB || N1]), || E(Kb, [Ks || IDA]), (3) E(Kb, [Ks || IDA]), (4) E(Ks, N2), , Authentication, steps, , (5) E(Ks, f(N2)), , Figure 14.3, , Key Distribution Scenario, , A has a master key, Ka, known only to itself and the KDC; similarly, B shares the, master key Kb with the KDC. The following steps occur., 1. A issues a request to the KDC for a session key to protect a logical connection, to B. The message includes the identity of A and B and a unique identifier, N1,, for this transaction, which we refer to as a nonce. The nonce may be a timestamp,, a counter, or a random number; the minimum requirement is that it differs with, each request. Also, to prevent masquerade, it should be difficult for an opponent, to guess the nonce. Thus, a random number is a good choice for a nonce., 2. The KDC responds with a message encrypted using Ka. Thus, A is the only one, who can successfully read the message, and A knows that it originated at the, KDC. The message includes two items intended for A:, ■ The one-time session key, Ks, to be used for the session, ■ The original request message, including the nonce, to enable A to match, this response with the appropriate request, Thus, A can verify that its original request was not altered before reception by, the KDC and, because of the nonce, that this is not a replay of some previous, request., In addition, the message includes two items intended for B:, ■ The one-time session key, Ks, to be used for the session, ■ An identifier of A (e.g., its network address), IDA, These last two items are encrypted with Kb (the master key that the KDC, shares with B). They are to be sent to B to establish the connection and prove, A’s identity.
Page 447 :
446, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , 3. A stores the session key for use in the upcoming session and forwards to B, the information that originated at the KDC for B, namely, E(Kb,[Ks } IDA])., Because this information is encrypted with Kb, it is protected from eavesdropping. B now knows the session key (Ks), knows that the other party is A (from, IDA), and knows that the information originated at the KDC (because it is, encrypted using Kb)., At this point, a session key has been securely delivered to A and B, and they, may begin their protected exchange. However, two additional steps are desirable:, 4. Using the newly minted session key for encryption, B sends a nonce, N2, to A., 5. Also, using Ks, A responds with f(N2), where f is a function that performs some, transformation on N2 (e.g., adding one)., These steps assure B that the original message it received (step 3) was not a replay., Note that the actual key distribution involves only steps 1 through 3, but that, steps 4 and 5, as well as step 3, perform an authentication function., , Hierarchical Key Control, It is not necessary to limit the key distribution function to a single KDC. Indeed, for, very large networks, it may not be practical to do so. As an alternative, a hierarchy, of KDCs can be established. For example, there can be local KDCs, each responsible for a small domain of the overall internetwork, such as a single LAN or a single, building. For communication among entities within the same local domain, the local, KDC is responsible for key distribution. If two entities in different domains desire a, shared key, then the corresponding local KDCs can communicate through a global, KDC. In this case, any one of the three KDCs involved can actually select the key., The hierarchical concept can be extended to three or even more layers, depending, on the size of the user population and the geographic scope of the internetwork., A hierarchical scheme minimizes the effort involved in master key distribution, because most master keys are those shared by a local KDC with its local, entities. Furthermore, such a scheme limits the damage of a faulty or subverted, KDC to its local area only., , Session Key Lifetime, The more frequently session keys are exchanged, the more secure they are, because, the opponent has less ciphertext to work with for any given session key. On the, other hand, the distribution of session keys delays the start of any exchange and, places a burden on network capacity. A security manager must try to balance these, competing considerations in determining the lifetime of a particular session key., For connection-oriented protocols, one obvious choice is to use the same session key for the length of time that the connection is open, using a new session key, for each new session. If a logical connection has a very long lifetime, then it would, be prudent to change the session key periodically, perhaps every time the PDU, (protocol data unit) sequence number cycles., For a connectionless protocol, such as a transaction-oriented protocol, there, is no explicit connection initiation or termination. Thus, it is not obvious how often, one needs to change the session key. The most secure approach is to use a new
Page 448 :
14.1 / SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION, , 447, , session key for each exchange. However, this negates one of the principal benefits, of connectionless protocols, which is minimum overhead and delay for each transaction. A better strategy is to use a given session key for a certain fixed period only or, for a certain number of transactions., , A Transparent Key Control Scheme, The approach suggested in Figure 14.3 has many variations, one of which is, described in this subsection. The scheme (Figure 14.4) is useful for providing, end-to-end encryption at a network or transport level in a way that is transparent to the end users. The approach assumes that communication makes use of a, connection-oriented end-to-end protocol, such as TCP. The noteworthy element of, this approach is a session security module (SSM), which may consist of functionality, Key, distribution, center, 1. Host sends packet requesting connection., 2. Security service buffers packet; asks, KDC for session key., 3. KDC distributes session key to both hosts., 4. Buffered packet transmitted., , 2, 3, , Application, , Application, 1, Security, service, , Network, Security, service, 4, , HOST, , Figure 14.4 Automatic Key Distribution for Connection-Oriented Protocol, , HOST
Page 449 :
448, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , at one protocol layer, that performs end-to-end encryption and obtains session keys, on behalf of its host or terminal., The steps involved in establishing a connection are shown in Figure 14.4. When, one host wishes to set up a connection to another host, it transmits a connectionrequest packet (step 1). The SSM saves that packet and applies to the KDC for, permission to establish the connection (step 2). The communication between the, SSM and the KDC is encrypted using a master key shared only by this SSM and, the KDC. If the KDC approves the connection request, it generates the session, key and delivers it to the two appropriate SSMs, using a unique permanent key for, each SSM (step 3). The requesting SSM can now release the connection request, packet, and a connection is set up between the two end systems (step 4). All user, data exchanged between the two end systems are encrypted by their respective SSMs, using the one-time session key., The automated key distribution approach provides the flexibility and dynamic, characteristics needed to allow a number of terminal users to access a number of, hosts and for the hosts to exchange data with each other., , Decentralized Key Control, The use of a key distribution center imposes the requirement that the KDC be, trusted and be protected from subversion. This requirement can be avoided if key, distribution is fully decentralized. Although full decentralization is not practical for, larger networks using symmetric encryption only, it may be useful within a local, context., A decentralized approach requires that each end system be able to communicate in a secure manner with all potential partner end systems for purposes of, session key distribution. Thus, there may need to be as many as [n(n - 1)]/2 master, keys for a configuration with n end systems., A session key may be established with the following sequence of steps, (Figure 14.5)., 1. A issues a request to B for a session key and includes a nonce, N1., 2. B responds with a message that is encrypted using the shared master key. The, response includes the session key selected by B, an identifier of B, the value, f(N1), and another nonce, N2., 3. Using the new session key, A returns f(N2) to B., (1) IDA || N1, , Initiator, A, , Responder, B, (2) E(Km, [Ks || IDA || IDB || f(N1) || N2 ]), , (3) E(Ks, f(N2)), , Figure 14.5, , Decentralized Key Distribution
Page 450 :
14.1 / SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION, , 449, , Thus, although each node must maintain at most (n - 1) master keys, as many, session keys as required may be generated and used. Because the messages transferred using the master key are short, cryptanalysis is difficult. As before, session, keys are used for only a limited time to protect them., , Controlling Key Usage, The concept of a key hierarchy and the use of automated key distribution techniques, greatly reduce the number of keys that must be manually managed and distributed., It also may be desirable to impose some control on the way in which automatically, distributed keys are used. For example, in addition to separating master keys from, session keys, we may wish to define different types of session keys on the basis of, use, such as, ■, ■, ■, , Data-encrypting key, for general communication across a network, PIN-encrypting key, for personal identification numbers (PINs) used in, electronic funds transfer and point-of-sale applications, File-encrypting key, for encrypting files stored in publicly accessible locations, , To illustrate the value of separating keys by type, consider the risk that a master, key is imported as a data-encrypting key into a device. Normally, the master key is, physically secured within the cryptographic hardware of the key distribution center, and of the end systems. Session keys encrypted with this master key are available to, application programs, as are the data encrypted with such session keys. However,, if a master key is treated as a session key, it may be possible for an unauthorized, application to obtain plaintext of session keys encrypted with that master key., Thus, it may be desirable to institute controls in systems that limit the ways, in which keys are used, based on characteristics associated with those keys. One, simple plan is to associate a tag with each key ([JONE82]; see also [DAVI89])., The proposed technique is for use with DES and makes use of the extra 8 bits in, each 64-bit DES key. That is, the eight non-key bits ordinarily reserved for parity, checking form the key tag. The bits have the following interpretation:, ■, ■, ■, ■, , One bit indicates whether the key is a session key or a master key, One bit indicates whether the key can be used for encryption, One bit indicates whether the key can be used for decryption, The remaining bits are spares for future use., , Because the tag is embedded in the key, it is encrypted along with the key when that, key is distributed, thus providing protection. The drawbacks of this scheme are, 1. The tag length is limited to 8 bits, limiting its flexibility and functionality., 2. Because the tag is not transmitted in clear form, it can be used only at the, point of decryption, limiting the ways in which key use can be controlled., A more flexible scheme, referred to as the control vector, is described in, [MATY91a and b]. In this scheme, each session key has an associated control vector, consisting of a number of fields that specify the uses and restrictions for that session, key. The length of the control vector may vary.
Page 451 :
450, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , Control, vector, , Master, key, , Session, key, , Hashing, function, , Master, key, , Encrypted, session key, , Hashing, function, , Key, input, , Figure 14.6, , Control, vector, , Plaintext, input, , Key, input, , Ciphertext, input, , Encryption, function, , Decryption, function, , Encrypted, session key, , Session key, , (a) Control vector encryption, , (b) Control vector decryption, , Control Vector Encryption and Decryption, , The control vector is cryptographically coupled with the key at the time of, key generation at the KDC. The coupling and decoupling processes are illustrated, in Figure 14.6. As a first step, the control vector is passed through a hash function that produces a value whose length is equal to the encryption key length. Hash, functions are discussed in detail in Chapter 11. In essence, a hash function maps, values from a larger range into a smaller range with a reasonably uniform spread., Thus, for example, if numbers in the range 1 to 100 are hashed into numbers in the, range 1 to 10, approximately 10% of the source values should map into each of the, target values., The hash value is then XORed with the master key to produce an output that, is used as the key input for encrypting the session key. Thus,, Hash value = H = h(CV), Key input = Km ⊕ H, Ciphertext = E([Km ⊕ H], Ks), where Km is the master key and Ks is the session key. The session key is recovered, in plaintext by the reverse operation:, D([Km ⊕ H], E([Km ⊕ H], Ks)), When a session key is delivered to a user from the KDC, it is accompanied, by the control vector in clear form. The session key can be recovered only by using, both the master key that the user shares with the KDC and the control vector. Thus,, the linkage between the session key and its control vector is maintained.
Page 452 :
14.2 / SYMMETRIC KEY DISTRIBUTION USING ASYMMETRIC ENCRYPTION, , 451, , Use of the control vector has two advantages over use of an 8-bit tag. First,, there is no restriction on length of the control vector, which enables arbitrarily complex controls to be imposed on key use. Second, the control vector is available in, clear form at all stages of operation. Thus, control of key use can be exercised in, multiple locations., , 14.2 SYMMETRIC KEY DISTRIBUTION USING, ASYMMETRIC ENCRYPTION, Because of the inefficiency of public-key cryptosystems, they are almost never used, for the direct encryption of sizable blocks of data, but are limited to relatively small, blocks. One of the most important uses of a public-key cryptosystem is to encrypt, secret keys for distribution. We see many specific examples of this in Part Five., Here, we discuss general principles and typical approaches., , Simple Secret Key Distribution, An extremely simple scheme was put forward by Merkle [MERK79], as illustrated, in Figure 14.7. If A wishes to communicate with B, the following procedure is, employed:, 1. A generates a public/private key pair {PUa, PRa} and transmits a message to B, consisting of PUa and an identifier of A, IDA., 2. B generates a secret key, Ks, and transmits it to A, which is encrypted with A’s, public key., 3. A computes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can, decrypt the message, only A and B will know the identity of Ks., 4. A discards PUa and PRa and B discards PUa., A and B can now securely communicate using conventional encryption and, the session key Ks. At the completion of the exchange, both A and B discard Ks., Despite its simplicity, this is an attractive protocol. No keys exist before the start of, the communication and none exist after the completion of communication. Thus,, the risk of compromise of the keys is minimal. At the same time, the communication, is secure from eavesdropping., The protocol depicted in Figure 14.7 is insecure against an adversary who can, intercept messages and then either relay the intercepted message or substitute another, message (see Figure 1.3c). Such an attack is known as a man-in-the-middle attack, [RIVE84]. We saw this type of attack in Chapter 10 (Figure 10.2). In the present, (1) PUa || IDA, , A, , B, (2) E(PUa, Ks), , Figure 14.7 Simple Use of Public-Key Encryption to Establish a Session Key, , Hiva-Network.Com
Page 453 :
452, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , case, if an adversary, D, has control of the intervening communication channel,, then D can compromise the communication in the following fashion without being, detected (Figure 14.8)., 1. A generates a public/private key pair {PUa, PRa} and transmits a message, intended for B consisting of PUa and an identifier of A, IDA., 2. D intercepts the message, creates its own public/private key pair {PUd, PRd}, and transmits PUd } IDA to B., 3. B generates a secret key, Ks, and transmits E(PUd, Ks)., 4. D intercepts the message and learns Ks by computing D(PRd, E(PUd, Ks))., 5. D transmits E(PUa, Ks) to A., , Alice, , Darth, , Bob, , Private key PRa, Public key PUa, PUa, IDA, Private key PRd, Public key PUd, PUd, IDA, , Private key PRb, Public key PUb, Secret key Ks, E(PUd, Ks), Ks =, D(PRd, E(PUd, Ks)), , E(PUa, Ks), , Alice, Bob, and, Darth share K1, , Figure 14.8 Another Man-in-the-Middle Attack
Page 454 :
14.2 / SYMMETRIC KEY DISTRIBUTION USING ASYMMETRIC ENCRYPTION, , 453, , The result is that both A and B know Ks and are unaware that Ks has also been, revealed to D. A and B can now exchange messages using Ks. D no longer actively, interferes with the communications channel but simply eavesdrops. Knowing Ks,, D can decrypt all messages, and both A and B are unaware of the problem. Thus,, this simple protocol is only useful in an environment where the only threat is, eavesdropping., , Secret Key Distribution with Confidentiality, and Authentication, Figure 14.9, based on an approach suggested in [NEED78], provides protection, against both active and passive attacks. We begin at a point when it is assumed that, A and B have exchanged public keys by one of the schemes described subsequently, in this chapter. Then the following steps occur., 1. A uses B’s public key to encrypt a message to B containing an identifier of, A(IDA) and a nonce (N1), which is used to identify this transaction uniquely., 2. B sends a message to A encrypted with PUa and containing A’s nonce (N1), as well as a new nonce generated by B (N2). Because only B could have, decrypted message (1), the presence of N1 in message (2) assures A that the, correspondent is B., 3. A returns N2, encrypted using B’s public key, to assure B that its correspondent is A., 4. A selects a secret key Ks and sends M = E(PUb, E(PRa, Ks)) to B. Encryption, of this message with B’s public key ensures that only B can read it; encryption, with A’s private key ensures that only A could have sent it., 5. B computes D(PUa, D(PRb, M)) to recover the secret key., The result is that this scheme ensures both confidentiality and authentication, in the exchange of a secret key., , (1) E(PUb, [N1 || IDA]), , (2) E(PUa, [N1 || N2]), , Initiator, A, , Responder, B, (3) E(PUb, N2), (4) E(PUb, E(PRa, Ks)), , Figure 14.9 Public-Key Distribution of Secret Keys
Page 455 :
454, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , A Hybrid Scheme, Yet another way to use public-key encryption to distribute secret keys is a hybrid, approach in use on IBM mainframes [LE93]. This scheme retains the use of a key, distribution center (KDC) that shares a secret master key with each user and distributes secret session keys encrypted with the master key. A public-key scheme is, used to distribute the master keys. The following rationale is provided for using this, three-level approach:, ■, , ■, , Performance: There are many applications, especially transaction-oriented, applications, in which the session keys change frequently. Distribution of session keys by public-key encryption could degrade overall system performance, because of the relatively high computational load of public-key encryption, and decryption. With a three-level hierarchy, public-key encryption is used, only occasionally to update the master key between a user and the KDC., Backward compatibility: The hybrid scheme is easily overlaid on an existing, KDC scheme with minimal disruption or software changes., , The addition of a public-key layer provides a secure, efficient means of distributing master keys. This is an advantage in a configuration in which a single KDC, serves a widely distributed set of users., , 14.3 DISTRIBUTION OF PUBLIC KEYS, Several techniques have been proposed for the distribution of public keys. Virtually, all these proposals can be grouped into the following general schemes:, ■, ■, ■, ■, , Public announcement, Publicly available directory, Public-key authority, Public-key certificates, , Public Announcement of Public Keys, On the face of it, the point of public-key encryption is that the public key is public., Thus, if there is some broadly accepted public-key algorithm, such as RSA, any, participant can send his or her public key to any other participant or broadcast the, key to the community at large (Figure 14.10). For example, because of the growing, popularity of PGP (pretty good privacy, discussed in Chapter 19), which makes use, of RSA, many PGP users have adopted the practice of appending their public key, to messages that they send to public forums, such as USENET newsgroups and, Internet mailing lists., Although this approach is convenient, it has a major weakness. Anyone can, forge such a public announcement. That is, some user could pretend to be user A, and send a public key to another participant or broadcast such a public key. Until, such time as user A discovers the forgery and alerts other participants, the forger is, able to read all encrypted messages intended for A and can use the forged keys for, authentication (see Figure 9.3).
Page 456 :
14.3 / DISTRIBUTION OF PUBLIC KEYS, , PUa, , PUb, , PUa, , PUb, , A, , Figure 14.10, , 455, , B, PUa, , PUb, , PUa, , PUb, , Uncontrolled Public-Key Distribution, , Public-key, directory, , PUa, , A, , PUb, , B, , Figure 14.11 Public-Key Publication, , Publicly Available Directory, A greater degree of security can be achieved by maintaining a publicly available, dynamic directory of public keys. Maintenance and distribution of the public, directory would have to be the responsibility of some trusted entity or organization, (Figure 14.11). Such a scheme would include the following elements:, 1. The authority maintains a directory with a {name, public key} entry for each, participant., 2. Each participant registers a public key with the directory authority., Registration would have to be in person or by some form of secure authenticated communication., 3. A participant may replace the existing key with a new one at any time, either, because of the desire to replace a public key that has already been used for, a large amount of data, or because the corresponding private key has been, compromised in some way., 4. Participants could also access the directory electronically. For this purpose,, secure, authenticated communication from the authority to the participant is, mandatory.
Page 457 :
456, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , This scheme is clearly more secure than individual public announcements, but still has vulnerabilities. If an adversary succeeds in obtaining or computing the, private key of the directory authority, the adversary could authoritatively pass out, counterfeit public keys and subsequently impersonate any participant and eavesdrop on messages sent to any participant. Another way to achieve the same end is, for the adversary to tamper with the records kept by the authority., , Public-Key Authority, Stronger security for public-key distribution can be achieved by providing tighter, control over the distribution of public keys from the directory. A typical scenario is, illustrated in Figure 14.12, which is based on a figure in [POPE79]. As before, the, scenario assumes that a central authority maintains a dynamic directory of public, keys of all participants. In addition, each participant reliably knows a public key for, the authority, with only the authority knowing the corresponding private key. The, following steps (matched by number to Figure 14.12) occur., 1. A sends a timestamped message to the public-key authority containing a, request for the current public key of B., 2. The authority responds with a message that is encrypted using the authority’s, private key, PRauth. Thus, A is able to decrypt the message using the authority’s public key. Therefore, A is assured that the message originated with the, authority. The message includes the following:, ■ B’s public key, PUb, which A can use to encrypt messages destined for B, ■ The original request used to enable A to match this response with the corresponding earlier request and to verify that the original request was not, altered before reception by the authority, ■ The original timestamp given so A can determine that this is not an old message from the authority containing a key other than B’s current public key, 3. A stores B’s public key and also uses it to encrypt a message to B containing, an identifier of A (IDA) and a nonce (N1), which is used to identify this transaction uniquely., 4, 5. B retrieves A’s public key from the authority in the same manner as A retrieved, B’s public key., At this point, public keys have been securely delivered to A and B, and they, may begin their protected exchange. However, two additional steps are desirable:, 6. B sends a message to A encrypted with PUa and containing A’s nonce (N1), as well as a new nonce generated by B (N2). Because only B could have, decrypted message (3), the presence of N1 in message (6) assures A that the, correspondent is B., 7. A returns N2, which is encrypted using B’s public key, to assure B that its, correspondent is A., Thus, a total of seven messages are required. However, the initial five, messages need be used only infrequently because both A and B can save the other’s, public key for future use—a technique known as caching. Periodically, a user should, request fresh copies of the public keys of its correspondents to ensure currency.
Page 458 :
14.3 / DISTRIBUTION OF PUBLIC KEYS, Public-key, authority, , Initiator A, , 457, , Responder B, , (1) Request || T1, (2) E(PRauth, [PUb || Request || T1]), (3) E(PUb, [ IDA || N1]), (4) Request || T2, (5) E(PRauth, [PUa || Request || T2]), (6) E(PUa, [ N1 || N2]), (7) E(PUb, N2), , Figure 14.12, , Public-Key Distribution Scenario, , Public-Key Certificates, The scenario of Figure 14.12 is attractive, yet it has some drawbacks. The public-key, authority could be somewhat of a bottleneck in the system, for a user must appeal, to the authority for a public key for every other user that it wishes to contact., As before, the directory of names and public keys maintained by the authority is, vulnerable to tampering., An alternative approach, first suggested by Kohnfelder [KOHN78], is to use, certificates that can be used by participants to exchange keys without contacting a, public-key authority, in a way that is as reliable as if the keys were obtained directly, from a public-key authority. In essence, a certificate consists of a public key, an, identifier of the key owner, and the whole block signed by a trusted third party., Typically, the third party is a certificate authority, such as a government agency or, a financial institution, that is trusted by the user community. A user can present, his or her public key to the authority in a secure manner and obtain a certificate., The user can then publish the certificate. Anyone needing this user’s public key can, obtain the certificate and verify that it is valid by way of the attached trusted signature. A participant can also convey its key information to another by transmitting, its certificate. Other participants can verify that the certificate was created by the, authority. We can place the following requirements on this scheme:, 1. Any participant can read a certificate to determine the name and public key of, the certificate’s owner., 2. Any participant can verify that the certificate originated from the certificate, authority and is not counterfeit., 3. Only the certificate authority can create and update certificates.
Page 459 :
458, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , These requirements are satisfied by the original proposal in [KOHN78]. Denning, [DENN83] added the following additional requirement:, 4. Any participant can verify the time validity of the certificate., A certificate scheme is illustrated in Figure 14.13. Each participant applies, to the certificate authority, supplying a public key and requesting a certificate., Application must be in person or by some form of secure authenticated communication. For participant A, the authority provides a certificate of the form, CA = E(PRauth, [T } IDA } PUa]), where PRauth is the private key used by the authority and T is a timestamp. A may, then pass this certificate on to any other participant, who reads and verifies the, certificate as follows:, D(PUauth, CA) = D(PUauth, E(PRauth, [T } IDA } PUa])) = (T } IDA } PUa), The recipient uses the authority’s public key, PUauth, to decrypt the certificate. Because the certificate is readable only using the authority’s public key, this, verifies that the certificate came from the certificate authority. The elements IDA, and PUa provide the recipient with the name and public key of the certificate’s, holder. The timestamp T validates the currency of the certificate. The timestamp, , Certificate, Authority, PUa, , PUb, , CA = E(PRauth, [T1 || IDA || PUa]), CB = E(PRauth, [T2 || IDB || PUb]), , A, , B, (a) Obtaining certificates from CA, , (1) CA, , A, , B, (2) CB, , (b) Exchanging certificates, , Figure 14.13, , Exchange of Public-Key Certificates
Page 460 :
14.4 / X.509 CERTIFICATES, , 459, , counters the following scenario. A’s private key is learned by an adversary., A generates a new private/public key pair and applies to the certificate authority, for a new certificate. Meanwhile, the adversary replays the old certificate to B. If B, then encrypts messages using the compromised old public key, the adversary can, read those messages., In this context, the compromise of a private key is comparable to the loss of a, credit card. The owner cancels the credit card number but is at risk until all possible, communicants are aware that the old credit card is obsolete. Thus, the timestamp, serves as something like an expiration date. If a certificate is sufficiently old, it is, assumed to be expired., One scheme has become universally accepted for formatting public-key, certificates: the X.509 standard. X.509 certificates are used in most network security, applications, including IP security, transport layer security (TLS), and S/MIME, all, of which are discussed in Part Five. X.509 is examined in detail in the next section., , 14.4 X.509 CERTIFICATES, ITU-T recommendation X.509 is part of the X.500 series of recommendations that, define a directory service. The directory is, in effect, a server or distributed set, of servers that maintains a database of information about users. The information, includes a mapping from user name to network address, as well as other attributes, and information about the users., X.509 defines a framework for the provision of authentication services by the, X.500 directory to its users. The directory may serve as a repository of public-key, certificates of the type discussed in Section 14.3. Each certificate contains the public, key of a user and is signed with the private key of a trusted certification authority., In addition, X.509 defines alternative authentication protocols based on the use of, public-key certificates., X.509 is an important standard because the certificate structure and authentication protocols defined in X.509 are used in a variety of contexts. For example, the, X.509 certificate format is used in S/MIME (Chapter 19), IP Security (Chapter 20),, and SSL/TLS (Chapter 17)., X.509 was initially issued in 1988. The standard was subsequently revised, in 1993 to address some of the security concerns documented in [IANS90] and, [MITC90]. The standard is currently at version 7, issued in 2012., X.509 is based on the use of public-key cryptography and digital signatures., The standard does not dictate the use of a specific digital signature algorithm nor a, specific hash function. Figure 14.14 illustrates the overall X.509 scheme for generation of a public-key certificate. The certificate for Bob’s public key includes unique, identifying information for Bob, Bob’s public key, and identifying information, about the CA, plus other information as explained subsequently. This information, is then signed by computing a hash value of the information and generating a digital, signature using the hash value and the CA’s private key. X.509 indicates that the, signature is formed by encrypting the hash value. This suggests the use of one of the, RSA schemes discussed in Section 13.6. However, the current version of X.509 does
Page 461 :
460, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , Unsigned certificate:, contains user ID,, user's public key, , H, , Bob's ID, information, Bob's public key, , H, , E, Generate hash, code of unsigned, certificate, , D, Signed certificate, , Encrypt hash code, with CA's private key, to form signature, , Create signed, digital certificate, , Figure 14.14, , Recipient can verify, signature by comparing, hash code values, , CA, information, , Decrypt signature, with CA's public key, to recover hash code, , Use certificate to, verify Bob's public key, , X.509 Public-Key Certificate Use, , not dictate a specific digital signature algorithm. If the NIST DSA (Section 13.4) or, the ECDSA (Section 13.5) scheme is used, then the hash value is not encrypted but, serves as input to a digital signature generation algorithm., , Certificates, The heart of the X.509 scheme is the public-key certificate associated with each, user. These user certificates are assumed to be created by some trusted certification, authority (CA) and placed in the directory by the CA or by the user. The directory, server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain, certificates., Figure 14.15a shows the general format of a certificate, which includes the, following elements., ■, , ■, ■, , Version: Differentiates among successive versions of the certificate format; the, default is version 1. If the issuer unique identifier or subject unique identifier, are present, the value must be version 2. If one or more extensions are present,, the version must be version 3. Although the X.509 specification is currently at, version 7, no changes have been made to the fields that make up the certificate, since version 3., Serial number: An integer value unique within the issuing CA that is unambiguously associated with this certificate., Signature algorithm identifier: The algorithm used to sign the certificate, together with any associated parameters. Because this information is repeated, in the signature field at the end of the certificate, this field has little, if any, utility., , Hiva-Network.Com
Page 462 :
14.4 / X.509 CERTIFICATES, Signature, algorithm, identifier, , Version, Certificate, serial number, , Signature, algorithm, identifier, , Version 2, , Subject name, Subject's, public key, info, , Algorithms, Parameters, Key, , Issuer unique, identifier, Subject unique, identifier, Extensions, Signature, , Revoked, certificate, , User certificate serial #, Revocation date, , •, •, •, Revoked, certificate, , User certificate serial #, Revocation date, , Signature, , Algorithms, Parameters, Signature of certificate, , (b) Certificate revocation list, All, versions, , Algorithms, Parameters, Signature of certificate, , Next update date, , Version 3, , Not before, Not after, , Period of, validity, , This update date, Version 1, , Issuer name, , Algorithm, Parameters, , Issuer name, , Algorithm, Parameters, , 461, , (a) X.509 certificate, , Figure 14.15, ■, ■, ■, , ■, , ■, , ■, ■, ■, , X.509 Formats, , Issuer name: X.500 name of the CA that created and signed this certificate., Period of validity: Consists of two dates: the first and last on which the certificate is valid., Subject name: The name of the user to whom this certificate refers. That is, this, certificate certifies the public key of the subject who holds the corresponding, private key., Subject’s public-key information: The public key of the subject, plus an identifier of the algorithm for which this key is to be used, together with any associated parameters., Issuer unique identifier: An optional-bit string field used to identify uniquely, the issuing CA in the event the X.500 name has been reused for different, entities., Subject unique identifier: An optional-bit string field used to identify uniquely, the subject in the event the X.500 name has been reused for different entities., Extensions: A set of one or more extension fields. Extensions were added in, version 3 and are discussed later in this section., Signature: Covers all of the other fields of the certificate. One component of, this field is the digital signature applied to the other fields of the certificate., This field includes the signature algorithm identifier., , The unique identifier fields were added in version 2 to handle the possible, reuse of subject and/or issuer names over time. These fields are rarely used.
Page 463 :
462, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , The standard uses the following notation to define a certificate:, CA V AW = CA {V, SN, AI, CA, UCA, A, UA, Ap, T A}, where, Y V X W = the certificate of user X issued by certification authority Y, Y {I} = the signing of I by Y. It consists of I with an encrypted hash, code appended, V = version of the certificate, SN = serial number of the certificate, AI = identifier of the algorithm used to sign the certificate, CA = name of certificate authority, UCA = optional unique identifier of the CA, A = name of user A, UA = optional unique identifier of the user A, Ap = public key of user A, T A = period of validity of the certificate, The CA signs the certificate with its private key. If the corresponding public, key is known to a user, then that user can verify that a certificate signed by the CA is, valid. This is the typical digital signature approach illustrated in Figure 13.2., OBTAINING A USER’S CERTIFICATE User certificates generated by a CA have the, following characteristics:, ■, ■, , Any user with access to the public key of the CA can verify the user public key, that was certified., No party other than the certification authority can modify the certificate, without this being detected., , Because certificates are unforgeable, they can be placed in a directory without the, need for the directory to make special efforts to protect them., If all users subscribe to the same CA, then there is a common trust of that CA., All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case,, once B is in possession of A’s certificate, B has confidence that messages it encrypts, with A’s public key will be secure from eavesdropping and that messages signed, with A’s private key are unforgeable., If there is a large community of users, it may not be practical for all users to, subscribe to the same CA. Because it is the CA that signs certificates, each participating user must have a copy of the CA’s own public key to verify signatures. This, public key must be provided to each user in an absolutely secure (with respect, to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be, a number of CAs, each of which securely provides its public key to some fraction, of the users.
Page 464 :
14.4 / X.509 CERTIFICATES, , 463, , Now suppose that A has obtained a certificate from certification authority, X 1 and B has obtained a certificate from CA X 2. If A does not securely know the, public key of X 2, then B’s certificate, issued by X 2, is useless to A. A can read B’s, certificate, but A cannot verify the signature. However, if the two CAs have securely, exchanged their own public keys, the following procedure will enable A to obtain, B’s public key., Step 1 A obtains from the directory the certificate of X 2 signed by X 1. Because, A securely knows X 1 >s public key, A can obtain X 2 >s public key from its, certificate and verify it by means of X 1 >s signature on the certificate., Step 2 A then goes back to the directory and obtains the certificate of B signed by, X 2. Because A now has a trusted copy of X 2 >s public key, A can verify the, signature and securely obtain B’s public key., A has used a chain of certificates to obtain B’s public key. In the notation of, X.509, this chain is expressed as, X1 V X2 W X2 V B W, In the same fashion, B can obtain A’s public key with the reverse chain:, X2 V X1 W X1 V A W, This scheme need not be limited to a chain of two certificates. An arbitrarily, long path of CAs can be followed to produce a chain. A chain with N elements, would be expressed as, X1 V X2 W X2 V X3 W c XN V B W, In this case, each pair of CAs in the chain (X i, X i + 1) must have created certificates for each other., All these certificates of CAs by CAs need to appear in the directory, and the, user needs to know how they are linked to follow a path to another user’s public-key, certificate. X.509 suggests that CAs be arranged in a hierarchy so that navigation is, straightforward., Figure 14.16, taken from X.509, is an example of such a hierarchy. The connected circles indicate the hierarchical relationship among the CAs; the associated, boxes indicate certificates maintained in the directory for each CA entry. The directory entry for each CA includes two types of certificates:, ■, , Forward certificates: Certificates of X generated by other CAs, , ■, , Reverse certificates: Certificates generated by X that are the certificates of, other CAs, , In this example, user A can acquire the following certificates from the directory to establish a certification path to B:, X VWW W VVW V VYW Y VZW Z VBW, When A has obtained these certificates, it can unwrap the certification path in, sequence to recover a trusted copy of B’s public key. Using this public key, A can, send encrypted messages to B. If A wishes to receive encrypted messages back
Page 465 : 464, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , U, U<<V>>, V<<U>>, , V, V<<W>>, W<<V>>, , W<<X>>, X<<W>>, X<<Z>>, , C, X<<C>>, , Figure 14.16, , W, , Y, , X, , V<<Y>>, Y<<V>>, , Z, , A, , X<<A>>, , Y<<Z>>, Z<<Y>>, Z<<X>>, , B, Z<<B>>, , X.509 Hierarchy: A Hypothetical Example, , from B, or to sign messages sent to B, then B will require A’s public key, which can, be obtained from the following certification path:, Z VYW Y VVW V VWW W VXW X VAW, B can obtain this set of certificates from the directory, or A can provide them, as part of its initial message to B., REVOCATION OF CERTIFICATES Recall from Figure 14.15 that each certificate includes, a period of validity, much like a credit card. Typically, a new certificate is issued just, before the expiration of the old one. In addition, it may be desirable on occasion to, revoke a certificate before it expires, for one of the following reasons., 1. The user’s private key is assumed to be compromised., 2. The user is no longer certified by this CA. Reasons for this include that the, subject’s name has changed, the certificate is superseded, or the certificate was, not issued in conformance with the CA’s policies., 3. The CA’s certificate is assumed to be compromised., Each CA must maintain a list consisting of all revoked but not expired, certificates issued by that CA, including both those issued to users and to other, CAs. These lists should also be posted on the directory.
Page 466 :
14.4 / X.509 CERTIFICATES, , 465, , Each certificate revocation list (CRL) posted to the directory is signed by the, issuer and includes (Figure 14.15b) the issuer’s name, the date the list was created,, the date the next CRL is scheduled to be issued, and an entry for each revoked, certificate. Each entry consists of the serial number of a certificate and revocation, date for that certificate. Because serial numbers are unique within a CA, the serial, number is sufficient to identify the certificate., When a user receives a certificate in a message, the user must determine, whether the certificate has been revoked. The user could check the directory each, time a certificate is received. To avoid the delays (and possible costs) associated, with directory searches, it is likely that the user would maintain a local cache of, certificates and lists of revoked certificates., , X.509 Version 3, The X.509 version 2 format does not convey all of the information that recent design, and implementation experience has shown to be needed. [FORD95] lists the following requirements not satisfied by version 2., 1. The subject field is inadequate to convey the identity of a key owner to a, public-key user. X.509 names may be relatively short and lacking in obvious, identification details that may be needed by the user., 2. The subject field is also inadequate for many applications, which typically, recognize entities by an Internet email address, a URL, or some other Internetrelated identification., 3. There is a need to indicate security policy information. This enables a security, application or function, such as IPSec, to relate an X.509 certificate to a given, policy., 4. There is a need to limit the damage that can result from a faulty or malicious, CA by setting constraints on the applicability of a particular certificate., 5. It is important to be able to identify different keys used by the same owner at, different times. This feature supports key lifecycle management: in particular,, the ability to update key pairs for users and CAs on a regular basis or under, exceptional circumstances., Rather than continue to add fields to a fixed format, standards developers, felt that a more flexible approach was needed. Thus, version 3 includes a number, of optional extensions that may be added to the version 2 format. Each extension, consists of an extension identifier, a criticality indicator, and an extension value., The criticality indicator indicates whether an extension can be safely ignored. If the, indicator has a value of TRUE and an implementation does not recognize the, extension, it must treat the certificate as invalid., The certificate extensions fall into three main categories: key and policy, information, subject and issuer attributes, and certification path constraints., KEY AND POLICY INFORMATION These extensions convey additional information, about the subject and issuer keys, plus indicators of certificate policy. A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security, requirements. For example, a policy might be applicable to the authentication of
Page 467 :
466, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , electronic data interchange (EDI) transactions for the trading of goods within a, given price range., This area includes:, ■, , ■, , ■, , ■, , ■, , ■, , Authority key identifier: Identifies the public key to be used to verify the, signature on this certificate or CRL. Enables distinct keys of the same CA to, be differentiated. One use of this field is to handle CA key pair updating., Subject key identifier: Identifies the public key being certified. Useful for subject key pair updating. Also, a subject may have multiple key pairs and, correspondingly, different certificates for different purposes (e.g., digital signature, and encryption key agreement)., Key usage: Indicates a restriction imposed as to the purposes for which, and, the policies under which, the certified public key may be used. May indicate, one or more of the following: digital signature, nonrepudiation, key encryption, data encryption, key agreement, CA signature verification on certificates,, CA signature verification on CRLs., Private-key usage period: Indicates the period of use of the private key corresponding to the public key. Typically, the private key is used over a different, period from the validity of the public key. For example, with digital signature, keys, the usage period for the signing private key is typically shorter than that, for the verifying public key., Certificate policies: Certificates may be used in environments where multiple, policies apply. This extension lists policies that the certificate is recognized as, supporting, together with optional qualifier information., Policy mappings: Used only in certificates for CAs issued by other CAs. Policy, mappings allow an issuing CA to indicate that one or more of that issuer’s, policies can be considered equivalent to another policy used in the subject, CA’s domain., , CERTIFICATE SUBJECT AND ISSUER ATTRIBUTES These extensions support alternative names, in alternative formats, for a certificate subject or certificate issuer and, can convey additional information about the certificate subject to increase a certificate user’s confidence that the certificate subject is a particular person or entity., For example, information such as postal address, position within a corporation, or, picture image may be required., The extension fields in this area include:, ■, , Subject alternative name: Contains one or more alternative names, using any, of a variety of forms. This field is important for supporting certain applications,, such as electronic mail, EDI, and IPSec, which may employ their own name, forms., , ■, , Issuer alternative name: Contains one or more alternative names, using any of, a variety of forms., Subject directory attributes: Conveys any desired X.500 directory attribute, values for the subject of this certificate., , ■
Page 468 :
14.5 / PUBLIC-KEY INFRASTRUCTURE, , 467, , CERTIFICATION PATH CONSTRAINTS These extensions allow constraint specifications, to be included in certificates issued for CAs by other CAs. The constraints may, restrict the types of certificates that can be issued by the subject CA or that may, occur subsequently in a certification chain., The extension fields in this area include:, ■, ■, ■, , Basic constraints: Indicates if the subject may act as a CA. If so, a certification, path length constraint may be specified., Name constraints: Indicates a name space within which all subject names in, subsequent certificates in a certification path must be located., Policy constraints: Specifies constraints that may require explicit certificate policy identification or inhibit policy mapping for the remainder of the, certification path., , 14.5 PUBLIC-KEY INFRASTRUCTURE, RFC 4949 (Internet Security Glossary) defines public-key infrastructure (PKI) as, the set of hardware, software, people, policies, and procedures needed to create,, manage, store, distribute, and revoke digital certificates based on asymmetric, cryptography. The principal objective for developing a PKI is to enable secure,, convenient, and efficient acquisition of public keys. The Internet Engineering Task, Force (IETF) Public Key Infrastructure X.509 (PKIX) working group has been the, driving force behind setting up a formal (and generic) model based on X.509 that is, suitable for deploying a certificate-based architecture on the Internet. This section, describes the PKIX model., Figure 14.17 shows the interrelationship among the key elements of the PKIX, model. These elements are, ■, , ■, , ■, , ■, ■, , End entity: A generic term used to denote end users, devices (e.g., servers,, routers), or any other entity that can be identified in the subject field of a, public-key certificate. End entities typically consume and/or support PKIrelated services., Certification authority (CA): The issuer of certificates and (usually) certificate revocation lists (CRLs). It may also support a variety of administrative, functions, although these are often delegated to one or more Registration, Authorities., Registration authority (RA): An optional component that can assume a number of administrative functions from the CA. The RA is often associated with, the end entity registration process but can assist in a number of other areas, as well., CRL issuer: An optional component that a CA can delegate to publish CRLs., Repository: A generic term used to denote any method for storing certificates, and CRLs so that they can be retrieved by end entities.
Page 469 :
CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , PKI, users, , Certificate/CRL retrieval, Certificate/CRL Repository, , 468, , End entity, Registration,, initialization,, , Registration, authority, Certificate, publication, Certificate/CRL, publication, , CRL, publication, , CRL issuer, , certification,, key pair recovery,, key pair update, revocation request, Certificate, authority, Cross, certification, Certificate, authority, , PKI, management, entities, Figure 14.17, , PKIX Architectural Model, , PKIX Management Functions, PKIX identifies a number of management functions that potentially need to be, supported by management protocols. These are indicated in Figure 14.17 and, include the following:, ■, , ■, , ■, , ■, , Registration: This is the process whereby a user first makes itself known to, a CA (directly or through an RA), prior to that CA issuing a certificate or, certificates for that user. Registration begins the process of enrolling in a PKI., Registration usually involves some offline or online procedure for mutual, authentication. Typically, the end entity is issued one or more shared secret, keys used for subsequent authentication., Initialization: Before a client system can operate securely, it is necessary to, install key materials that have the appropriate relationship with keys stored, elsewhere in the infrastructure. For example, the client needs to be securely, initialized with the public key and other assured information of the trusted, CA(s), to be used in validating certificate paths., Certification: This is the process in which a CA issues a certificate for a user’s, public key, returns that certificate to the user’s client system, and/or posts that, certificate in a repository., Key pair recovery: Key pairs can be used to support digital signature creation, and verification, encryption and decryption, or both. When a key pair is used for
Page 470 :
14.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , ■, , ■, , ■, , 469, , encryption/decryption, it is important to provide a mechanism to recover the, necessary decryption keys when normal access to the keying material is no longer, possible, otherwise it will not be possible to recover the encrypted data. Loss of, access to the decryption key can result from forgotten passwords/PINs, corrupted, disk drives, damage to hardware tokens, and so on. Key pair recovery allows end, entities to restore their encryption/decryption key pair from an authorized key, backup facility (typically, the CA that issued the end entity’s certificate)., Key pair update: All key pairs need to be updated regularly (i.e., replaced, with a new key pair) and new certificates issued. Update is required when the, certificate lifetime expires and as a result of certificate revocation., Revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation. Reasons for revocation include privatekey compromise, change in affiliation, and name change., Cross certification: Two CAs exchange information used in establishing a, cross-certificate. A cross-certificate is a certificate issued by one CA to another, CA that contains a CA signature key used for issuing certificates., , PKIX Management Protocols, The PKIX working group has defines two alternative management protocols, between PKIX entities that support the management functions listed in the preceding subsection. RFC 2510 defines the certificate management protocols (CMP)., Within CMP, each of the management functions is explicitly identified by specific, protocol exchanges. CMP is designed to be a flexible protocol able to accommodate, a variety of technical, operational, and business models., RFC 2797 defines certificate management messages over CMS (CMC), where, CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work, and is intended to leverage existing implementations. Although all of the PKIX functions are supported, the functions do not all map into specific protocol exchanges., , 14.6 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, end-to-end encryption, key distribution, key distribution center (KDC), key management, , man-in-the-middle attack, master key, nonce, public-key certificate, , public-key directory, X.509 certificate, , Review Questions, 14.1, 14.2, 14.3, 14.4, 14.5, , Explain why man-in-the-middle attacks are ineffective on the secret key distribution, protocol discussed in Figure 14.3., What is the major issue in end to end key distribution? How does the key hierarchy, concept address that issue?, What is a nonce?, What is a key distribution center?, What are two different uses of public-key cryptography related to key distribution?, , Hiva-Network.Com
Page 471 :
470, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, 14.6, 14.7, 14.8, 14.9, 14.10, 14.11, 14.12, , List four general categories of schemes for the distribution of public keys., Discuss the potential security issues that arise due to public key directory based, system., What is a public-key certificate?, What are the requirements for the use of a public-key certificate scheme?, What is the purpose of the X.509 standard?, What is a chain of certificates?, How is an X.509 certificate revoked?, , Problems, 14.1, , 14.2, , One local area network vendor provides a key distribution facility, as illustrated in, Figure 14.18., a. Describe the scheme., b. Compare this scheme to that of Figure 14.3. What are the pros and cons?, “We are under great pressure, Holmes.” Detective Lestrade looked nervous. “We, have learned that copies of sensitive government documents are stored in computers, of one foreign embassy here in London. Normally these documents exist in electronic, form only on a selected few government computers that satisfy the most stringent, security requirements. However, sometimes they must be sent through the network, connecting all government computers. But all messages in this network are encrypted, using a top-secret encryption algorithm certified by our best crypto experts. Even the, NSA and the KGB are unable to break it. And now these documents have appeared, in hands of diplomats of a small, otherwise insignificant, country. And we have no, idea how it could happen.”, “But you do have some suspicion who did it, do you?” asked Holmes., “Yes, we did some routine investigation. There is a man who has legal access, to one of the government computers and has frequent contacts with diplomats from, the embassy. But the computer he has access to is not one of the trusted ones where, these documents are normally stored. He is the suspect, but we have no idea how he, could obtain copies of the documents. Even if he could obtain a copy of an encrypted, document, he couldn’t decrypt it.”, , Key, Distribution, Center (KDC), (2) IDA, E(Ka, Na), IDB, E(Kb, Nb), , (3) E(Kb, [Ks, IDA, Nb]), E(Ka, [Ks, IDB, Na]), , (1) IDA, E(Ka, Na), , B, , A, (4) E(Ka, [Ks, IDB, Na]), , Figure 14.18, , Figure for Problem 14.1
Page 472 :
14.6 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 471, , “Hmm, please describe the communication protocol used on the network.”, Holmes opened his eyes, thus proving that he had followed Lestrade’s talk with an, attention that contrasted with his sleepy look., “Well, the protocol is as follows. Each node N of the network has been assigned, a unique secret key Kn. This key is used to secure communication between the node, and a trusted server. That is, all the keys are stored also on the server. User A, wishing, to send a secret message M to user B, initiates the following protocol:, , 1. A generates a random number R and sends to the server his name A, destination, B, and E(Ka, R)., , 2. Server responds by sending E(Kb, R) to A., 3. A sends E(R, M) together with E(Kb, R) to B., 4. B knows Kb, thus decrypts E(Kb, R), to get R and will subsequently use R to, decrypt E(R, M) to get M., , 14.3, , You see that a random key is generated every time a message has to be sent. I admit, the man could intercept messages sent between the top-secret trusted nodes, but I see, no way he could decrypt them.”, “Well, I think you have your man, Lestrade. The protocol isn’t secure because, the server doesn’t authenticate users who send him a request. Apparently designers, of the protocol have believed that sending E(Kx, R) implicitly authenticates user X as, the sender, as only X (and the server) knows Kx. But you know that E(Kx, R) can be, intercepted and later replayed. Once you understand where the hole is, you will be, able to obtain enough evidence by monitoring the man’s use of the computer he has, access to. Most likely he works as follows. After intercepting E(Ka, R) and E(R, M), (see steps 1 and 3 of the protocol), the man, let’s denote him as Z, will continue by, pretending to be A and . . ., Finish the sentence for Holmes., The 1988 version of X.509 lists properties that RSA keys must satisfy to be secure, given current knowledge about the difficulty of factoring large numbers. The discussion concludes with a constraint on the public exponent and the modulus n:, It must be ensured that e 7 log 2(n) to prevent attack by taking the eth, root mod n to disclose the plaintext., , 14.4, , 14.5, , Although the constraint is correct, the reason given for requiring it is incorrect. What, is wrong with the reason given and what is the correct reason?, Find at least one intermediate certification authority’s certificate and one trusted, root certification authority’s certificate on your computer (e.g., in the browser). Print, screenshots of both the general and details tab for each certificate., NIST defines the term cryptoperiod as the time span during which a specific key is, authorized for use or in which the keys for a given system or application may remain, in effect. One document on key management uses the following time diagram for, a shared secret key., , Originator usage period, Recipient usage period, Cryptoperiod
Page 473 :
472, , CHAPTER 14 / KEY MANAGEMENT AND DISTRIBUTION, , 14.6, , 14.7, 14.8, , Explain the overlap by giving an example application in which the originator’s usage, period for the shared secret key begins before the recipient’s usage period and also, ends before the recipients usage period., Consider the following protocol, designed to let A and B decide on a fresh, shared, =, session key KAB, . We assume that they already share a long-term key KAB., 1. A S B: A, NA., =, 2. B S A: E(KAB, [NA, KAB, ]), =, 3. A S B: E(KAB, , NA), a. We first try to understand the protocol designer’s reasoning:, =, —Why would A and B believe after the protocol ran that they share KAB, with the, other party?, —Why would they believe that this shared key is fresh?, In both cases, you should explain both the reasons of both A and B, so your answer, should complete the sentences, =, A believes that she shares KAB, with B since . . ., =, B believes that he shares KAB, with A since . . ., =, A believes that KAB, is fresh since . . ., =, B believes that KAB, is fresh since . . ., b. Assume now that A starts a run of this protocol with B. However, the connection, is intercepted by the adversary C. Show how C can start a new run of the protocol, using reflection, causing A to believe that she has agreed on a fresh key with B (in, spite of the fact that she has only been communicating with C). Thus, in particular,, the belief in (a) is false., c. Propose a modification of the protocol that prevents this attack., What are the management functions of a PKI? What is a cross certificate?, State the significance of key pair recovery. When is the key pair updated?, , Note: The remaining problems deal with the a cryptographic product developed by IBM,, which is briefly described in a document at box.com/Crypto7e (IBMCrypto.pdf). Try these, problems after reviewing the document., 14.9, , What is the effect of adding the instruction EMKi, EMK i: X S E(KMHi, X) i = 0, 1, , 14.10, , 14.11, , Suppose N different systems use the IBM Cryptographic Subsystem with host master, keys KMH[i](i = 1, 2, c N). Devise a method for communicating between systems without requiring the system to either share a common host master key or to, divulge their individual host master keys. Hint: Each system needs three variants of, its host master key., The principal objective of the IBM Cryptographic Subsystem is to protect transmissions between a terminal and the processing system. Devise a procedure, perhaps, adding instructions, which will allow the processor to generate a session key KS and, distribute it to Terminal i and Terminal j without having to store a key-equivalent, variable in the host.
Page 474 :
CHAPTER, , User Authentication, 15.1 Remote User-Authentication Principles, The NIST Model for Electronic User Authentication, Means of Authentication, Mutual Authentication, One-Way Authentication, 15.2 Remote User-Authentication Using Symmetric Encryption, Mutual Authentication, One-Way Authentication, 15.3 Kerberos, Motivation, Kerberos Version 4, Kerberos Version 5, 15.4 Remote User-Authentication Using Asymmetric Encryption, Mutual Authentication, One-Way Authentication, 15.5 Federated Identity Management, Identity Management, Identity Federation, 15.6 Personal Identity Verification, PIV System Model, PIV Documentation, PIV Credentials and Keys, Authentication, 15.7 Key Terms, Review Questions, and Problems, , 473
Page 475 :
474, , CHAPTER 15 / USER AUTHENTICATION, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Understand the distinction between identification and verification., ◆ Present an overview of techniques for remote user authentication using, symmetric encryption., ◆ Give a presentation on Kerberos., ◆ Explain the differences between versions 4 and 5 of Kerberos., ◆ Describe the use of Kerberos in multiple realms., ◆ Present an overview of techniques for remote user authentication using, asymmetric encryption., ◆ Understand the need for a federated identity management system., ◆ Explain the use of PIV mechanisms as part of a user authentication system., , This chapter examines some of the authentication functions that have been developed, to support network-based user authentication. The chapter begins with an introduction to some of the concepts and key considerations for user authentication over a, network or the Internet. The next section examines user-authentication protocols that, rely on symmetric encryption. This is followed by a section on one of the earliest and, also one of the most widely used authentication services: Kerberos. Next, the chapter, looks at user-authentication protocols that rely on asymmetric encryption. This is followed by a discussion of the X.509 user-authentication protocol. Finally, the concept of, federated identity is introduced., , 15.1 REMOTE USER-AUTHENTICATION PRINCIPLES, In most computer security contexts, user authentication is the fundamental building block and the primary line of defense. User authentication is the basis for most, types of access control and for user accountability. RFC 4949 (Internet Security, Glossary) defines user authentication as the process of verifying an identity claimed, by or for a system entity. This process consists of two steps:, ■, , ■, , Identification step: Presenting an identifier to the security system. (Identifiers, should be assigned carefully, because authenticated identities are the basis for, other security services, such as access control service.), Verification step: Presenting or generating authentication information that, corroborates the binding between the entity and the identifier., , For example, user Alice Toklas could have the user identifier ABTOKLAS., This information needs to be stored on any server or computer system that Alice, wishes to use and could be known to system administrators and other users.
Page 476 :
15.1 / REMOTE USER-AUTHENTICATION PRINCIPLES, , 475, , A typical item of authentication information associated with this user ID is a password, which is kept secret (known only to Alice and to the system). If no one is, able to obtain or guess Alice’s password, then the combination of Alice’s user ID, and password enables administrators to set up Alice’s access permissions and audit, her activity. Because Alice’s ID is not secret, system users can send her email, but, because her password is secret, no one can pretend to be Alice., In essence, identification is the means by which a user provides a claimed, identity to the system; user authentication is the means of establishing the validity, of the claim. Note that user authentication is distinct from message authentication., As defined in Chapter 12, message authentication is a procedure that allows communicating parties to verify that the contents of a received message have not been, altered and that the source is authentic. This chapter is concerned solely with user, authentication., , The NIST Model for Electronic User Authentication, NIST SP 800-63-2 (Electronic Authentication Guideline, August 2013) defines electronic user authentication as the process of establishing confidence in user identities that are presented electronically to an information system. Systems can use the, authenticated identity to determine if the authenticated individual is authorized to, perform particular functions, such as database transactions or access to system resources. In many cases, the authentication and transaction or other authorized function, takes place across an open network such as the Internet. Equally authentication and, subsequent authorization can take place locally, such as across a local area network., SP 800-63-2 defines a general model for user authentication that involves a number of entities and procedures. We discuss this model with reference to Figure 15.1., The initial requirement for performing user authentication is that the user, must be registered with the system. The following is a typical sequence for registration. An applicant applies to a registration authority (RA) to become a subscriber, , Registration, credential issuance,, and maintenance, Registration, authority (RA), , Identity proofing, User registration, , Registration, Confirmation, , Credential, service, provider (RA), , ial ce, nt, de suan, e, r, , c /is, en tion, k, a, To istr, g, Re, , Subscriber/, claimant, , Authenticated session, Au, t, , Relying, party (RP), , he, , Authenticated, nt, i, assertion, Ex cat, ch ed, an pro, ge to, co, l, , Token/credential, Validation, , Verifier, , E-Authentication using, token and credential, Figure 15.1, , The NIST SP 800-63-2 E-Authentication Architectural Model
Page 477 :
476, , CHAPTER 15 / USER AUTHENTICATION, , of a credential service provider (CSP). In this model, the RA is a trusted entity that, establishes and vouches for the identity of an applicant to a CSP. The CSP then, engages in an exchange with the subscriber. Depending on the details of the overall authentication system, the CSP issues some sort of electronic credential to the, subscriber. The credential is a data structure that authoritatively binds an identity, and additional attributes to a token possessed by a subscriber, and can be verified, when presented to the verifier in an authentication transaction. The token could, be an encryption key or an encrypted password that identifies the subscriber. The, token may be issued by the CSP, generated directly by the subscriber, or provided, by a third party. The token and credential may be used in subsequent authentication events., Once a user is registered as a subscriber, the actual authentication process can, take place between the subscriber and one or more systems that perform authentication and, subsequently, authorization. The party to be authenticated is called a, claimant and the party verifying that identity is called a verifier. When a claimant, successfully demonstrates possession and control of a token to a verifier through an, authentication protocol, the verifier can verify that the claimant is the subscriber, named in the corresponding credential. The verifier passes on an assertion about the, identity of the subscriber to the relying party (RP). That assertion includes identity, information about a subscriber, such as the subscriber name, an identifier assigned, at registration, or other subscriber attributes that were verified in the registration, process. The RP can use the authenticated information provided by the verifier to, make access control or authorization decisions., An implemented system for authentication will differ from or be more complex than this simplified model, but the model illustrates the key roles and functions, needed for a secure authentication system., , Means of Authentication, There are four general means of authenticating a user’s identity, which can be used, alone or in combination:, ■, ■, , ■, ■, , Something the individual knows: Examples include a password, a personal, identification number (PIN), or answers to a prearranged set of questions., Something the individual possesses: Examples include cryptographic keys,, electronic keycards, smart cards, and physical keys. This type of authenticator, is referred to as a token., Something the individual is (static biometrics): Examples include recognition, by fingerprint, retina, and face., Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm., , All of these methods, properly implemented and used, can provide secure, user authentication. However, each method has problems. An adversary may be, able to guess or steal a password. Similarly, an adversary may be able to forge or, steal a token. A user may forget a password or lose a token. Furthermore, there is a, significant administrative overhead for managing password and token information, on systems and securing such information on systems. With respect to biometric
Page 478 :
15.1 / REMOTE USER-AUTHENTICATION PRINCIPLES, , 477, , authenticators, there are a variety of problems, including dealing with false positives, and false negatives, user acceptance, cost, and convenience. For network-based user, authentication, the most important methods involve cryptographic keys and something the individual knows, such as a password., , Mutual Authentication, An important application area is that of mutual authentication protocols. Such protocols enable communicating parties to satisfy themselves mutually about each other’s identity and to exchange session keys. This topic was examined in Chapter 14., There, the focus was key distribution. We return to this topic here to consider the, wider implications of authentication., Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness. To prevent masquerade and to prevent compromise of, session keys, essential identification and session-key information must be communicated in encrypted form. This requires the prior existence of secret or public keys, that can be used for this purpose. The second issue, timeliness, is important because, of the threat of message replays. Such replays, at worst, could allow an opponent to, compromise a session key or successfully impersonate another party. At minimum,, a successful replay can disrupt operations by presenting parties with messages that, appear genuine but are not., [GONG93] lists the following examples of replay attacks:, 1. The simplest replay attack is one in which the opponent simply copies a message and replays it later., 2. An opponent can replay a timestamped message within the valid time window., If both the original and the replay arrive within then time window, this incident can be logged., 3. As with example (2), an opponent can replay a timestamped message within, the valid time window, but in addition, the opponent suppresses the original, message. Thus, the repetition cannot be detected., 4. Another attack involves a backward replay without modification. This is a replay back to the message sender. This attack is possible if symmetric encryption is used and the sender cannot easily recognize the difference between, messages sent and messages received on the basis of content., One approach to coping with replay attacks is to attach a sequence number to, each message used in an authentication exchange. A new message is accepted only, if its sequence number is in the proper order. The difficulty with this approach is, that it requires each party to keep track of the last sequence number for each claimant it has dealt with. Because of this overhead, sequence numbers are generally not, used for authentication and key exchange. Instead, one of the following two general, approaches is used:, ■, , Timestamps: Party A accepts a message as fresh only if the message contains, a timestamp that, in A’s judgment, is close enough to A’s knowledge of current time. This approach requires that clocks among the various participants, be synchronized.
Page 479 :
478, , CHAPTER 15 / USER AUTHENTICATION, ■, , Challenge/response: Party A, expecting a fresh message from B, first sends B, a nonce (challenge) and requires that the subsequent message (response) received from B contain the correct nonce value., , It can be argued (e.g., [LAM92a]) that the timestamp approach should not be, used for connection-oriented applications because of the inherent difficulties with, this technique. First, some sort of protocol is needed to maintain synchronization, among the various processor clocks. This protocol must be both fault tolerant, to, cope with network errors, and secure, to cope with hostile attacks. Second, the opportunity for a successful attack will arise if there is a temporary loss of synchronization, resulting from a fault in the clock mechanism of one of the parties. Finally, because, of the variable and unpredictable nature of network delays, distributed clocks cannot, be expected to maintain precise synchronization. Therefore, any timestamp-based, procedure must allow for a window of time sufficiently large to accommodate network delays yet sufficiently small to minimize the opportunity for attack., On the other hand, the challenge-response approach is unsuitable for a connectionless type of application, because it requires the overhead of a handshake before any connectionless transmission, effectively negating the chief characteristic of, a connectionless transaction. For such applications, reliance on some sort of secure, time server and a consistent attempt by each party to keep its clocks in synchronization may be the best approach (e.g., [LAM92b])., , One-Way Authentication, One application for which encryption is growing in popularity is electronic mail, (email). The very nature of electronic mail, and its chief benefit, is that it is not necessary for the sender and receiver to be online at the same time. Instead, the email, message is forwarded to the receiver’s electronic mailbox, where it is buffered until, the receiver is available to read it., The “envelope” or header of the email message must be in the clear, so that, the message can be handled by the store-and-forward email protocol, such as the, Simple Mail Transfer Protocol (SMTP) or X.400. However, it is often desirable that, the mail-handling protocol not require access to the plaintext form of the message,, because that would require trusting the mail-handling mechanism. Accordingly, the, email message should be encrypted such that the mail-handling system is not in, possession of the decryption key., A second requirement is that of authentication. Typically, the recipient wants, some assurance that the message is from the alleged sender., , 15.2 REMOTE USER-AUTHENTICATION USING, SYMMETRIC ENCRYPTION, Mutual Authentication, As was discussed in Chapter 14, a two-level hierarchy of symmetric encryption keys, can be used to provide confidentiality for communication in a distributed environment. In general, this strategy involves the use of a trusted key distribution center, , Hiva-Network.Com
Page 480 :
15.2 / REMOTE USER-AUTHENTICATION USING SYMMETRIC ENCRYPTION, , 479, , (KDC). Each party in the network shares a secret key, known as a master key, with, the KDC. The KDC is responsible for generating keys to be used for a short time, over a connection between two parties, known as session keys, and for distributing those keys using the master keys to protect the distribution. This approach is, quite common. As an example, we look at the Kerberos system in Section 15.3., The discussion in this subsection is relevant to an understanding of the Kerberos, mechanisms., Figure 14.3 illustrates a proposal initially put forth by Needham and Schroeder, [NEED78] for secret key distribution using a KDC that, as was mentioned in, Chapter 14, includes authentication features. The protocol can be summarized as, follows.1, 1., 2., 3., 4., 5., , A S KDC:, KDC S A:, A S B:, B S A:, A S B:, , IDA } IDB } N1, E(Ka, [Ks } IDB } N1 } E(Kb, [Ks } IDA])]), E(Kb, [Ks } IDA]), E(Ks, N2), E(Ks, f(N2)) where f() is a generic function that modifies the, value of the nonce., , Secret keys Ka and Kb are shared between A and the KDC and B and the, KDC, respectively. The purpose of the protocol is to distribute securely a session, key Ks to A and B. Entity A securely acquires a new session key in step 2. The message in step 3 can be decrypted, and hence understood, only by B. Step 4 reflects B’s, knowledge of Ks, and step 5 assures B of A’s knowledge of Ks and assures B that this, is a fresh message because of the use of the nonce N2. Recall from our discussion in, Chapter 14 that the purpose of steps 4 and 5 is to prevent a certain type of replay attack. In particular, if an opponent is able to capture the message in step 3 and replay, it, this might in some fashion disrupt operations at B., Despite the handshake of steps 4 and 5, the protocol is still vulnerable to a, form of replay attack. Suppose that an opponent, X, has been able to compromise, an old session key. Admittedly, this is a much more unlikely occurrence than that, an opponent has simply observed and recorded step 3. Nevertheless, it is a potential, security risk. X can impersonate A and trick B into using the old key by simply replaying step 3. Unless B remembers indefinitely all previous session keys used with, A, B will be unable to determine that this is a replay. If X can intercept the handshake message in step 4, then it can impersonate A’s response in step 5. From this, point on, X can send bogus messages to B that appear to B to come from A using an, authenticated session key., Denning [DENN81, DENN82] proposes to overcome this weakness by a, modification to the Needham/Schroeder protocol that includes the addition of a, timestamp to steps 2 and 3. Her proposal assumes that the master keys, Ka and Kb,, are secure, and it consists of the following steps., , 1, , The portion to the left of the colon indicates the sender and the receiver; the portion to the right indicates the contents of the message; the symbol } indicates concatenation.
Page 481 :
480, , CHAPTER 15 / USER AUTHENTICATION, , 1., 2., 3., 4., 5., , A S KDC:, KDC S A:, A S B:, B S A:, A S B:, , IDA } IDB, E(Ka, [Ks } IDB } T } E(Kb, [Ks } IDA } T])]), E(Kb, [Ks } IDA } T]), E(Ks, N1), E(Ks, f(N1)), , T is a timestamp that assures A and B that the session key has only just been, generated. Thus, both A and B know that the key distribution is a fresh exchange., A and B can verify timeliness by checking that, Clock - T 6 ∆t 1 + ∆t 2, where ∆t 1 is the estimated normal discrepancy between the KDC’s clock and the, local clock (at A or B) and ∆t 2 is the expected network delay time. Each node can, set its clock against some standard reference source. Because the timestamp T is, encrypted using the secure master keys, an opponent, even with knowledge of an, old session key, cannot succeed because a replay of step 3 will be detected by B as, untimely., A final point: Steps 4 and 5 were not included in the original presentation, [DENN81] but were added later [DENN82]. These steps confirm the receipt of the, session key at B., The Denning protocol seems to provide an increased degree of security compared to the Needham/Schroeder protocol. However, a new concern is raised:, namely, that this new scheme requires reliance on clocks that are synchronized, throughout the network. [GONG92] points out a risk involved. The risk is based, on the fact that the distributed clocks can become unsynchronized as a result of, sabotage on or faults in the clocks or the synchronization mechanism.2 The problem, occurs when a sender’s clock is ahead of the intended recipient’s clock. In this case,, an opponent can intercept a message from the sender and replay it later when the, timestamp in the message becomes current at the recipient’s site. This replay could, cause unexpected results. Gong refers to such attacks as suppress-replay attacks., One way to counter suppress-replay attacks is to enforce the requirement that, parties regularly check their clocks against the KDC’s clock. The other alternative,, which avoids the need for clock synchronization, is to rely on handshaking protocols, using nonces. This latter alternative is not vulnerable to a suppress-replay attack,, because the nonces the recipient will choose in the future are unpredictable to the, sender. The Needham/Schroeder protocol relies on nonces only but, as we have, seen, has other vulnerabilities., In [KEHN92], an attempt is made to respond to the concerns about suppressreplay attacks and at the same time fix the problems in the Needham/Schroeder, protocol. Subsequently, an inconsistency in this latter protocol was noted and an, improved strategy was presented in [NEUM93a].3 The protocol is, , 2, Such things can and do happen. In recent years, flawed chips were used in a number of computers and other, electronic systems to track the time and date. The chips had a tendency to skip forward one day. [NEUM90], 3, It really is hard to get these things right.
Page 482 :
15.2 / REMOTE USER-AUTHENTICATION USING SYMMETRIC ENCRYPTION, , 1., 2., 3., 4., , 481, , A S B:, IDA } Na, B S KDC: IDB } Nb } E(K b, [IDA } Na } Tb]), KDC S A: E(Ka, [IDB } Na } Ks } Tb]) } E(Kb, [IDA } Ks } Tb]) } Nb, A S B:, E(Kb, [IDA } Ks } Tb]) } E(Ks, Nb), Let us follow this exchange step by step., , 1. A initiates the authentication exchange by generating a nonce, Na, and sending, that plus its identifier to B in plaintext. This nonce will be returned to A in an, encrypted message that includes the session key, assuring A of its timeliness., 2. B alerts the KDC that a session key is needed. Its message to the KDC includes its identifier and a nonce, Nb. This nonce will be returned to B in an, encrypted message that includes the session key, assuring B of its timeliness., B’s message to the KDC also includes a block encrypted with the secret key, shared by B and the KDC. This block is used to instruct the KDC to issue, credentials to A; the block specifies the intended recipient of the credentials, a, suggested expiration time for the credentials, and the nonce received from A., 3. The KDC passes on to A B’s nonce and a block encrypted with the secret key, that B shares with the KDC. The block serves as a “ticket” that can be used, by A for subsequent authentications, as will be seen. The KDC also sends to, A a block encrypted with the secret key shared by A and the KDC. This block, verifies that B has received A’s initial message (IDB) and that this is a timely, message and not a replay (Na), and it provides A with a session key (Ks) and, the time limit on its use (Tb)., 4. A transmits the ticket to B, together with the B’s nonce, the latter encrypted, with the session key. The ticket provides B with the secret key that is used to decrypt E(Ks, Nb) to recover the nonce. The fact that B’s nonce is encrypted with, the session key authenticates that the message came from A and is not a replay., This protocol provides an effective, secure means for A and B to establish a, session with a secure session key. Furthermore, the protocol leaves A in possession of a key that can be used for subsequent authentication to B, avoiding the, need to contact the authentication server repeatedly. Suppose that A and B establish a session using the aforementioned protocol and then conclude that session., Subsequently, but within the time limit established by the protocol, A desires a new, session with B. The following protocol ensues:, 1. A S B: E(Kb, [IDA } Ks } Tb]) } Na=, 2. B S A: Nb= } E(Ks, Na= ), 3. A S B: E(Ks, Nb= ), When B receives the message in step 1, it verifies that the ticket has not expired., The newly generated nonces Na= and Nb= assure each party that there is no replay, attack., In all the foregoing, the time specified in Tb is a time relative to B’s clock., Thus, this timestamp does not require synchronized clocks, because B checks only, self-generated timestamps.
Page 483 :
482, , CHAPTER 15 / USER AUTHENTICATION, , One-Way Authentication, Using symmetric encryption, the decentralized key distribution scenario illustrated, in Figure 14.5 is impractical. This scheme requires the sender to issue a request to, the intended recipient, await a response that includes a session key, and only then, send the message., With some refinement, the KDC strategy illustrated in Figure 14.3 is a candidate for encrypted electronic mail. Because we wish to avoid requiring that the, recipient (B) be on line at the same time as the sender (A), steps 4 and 5 must be, eliminated. For a message with content M, the sequence is as follows:, 1. A S KDC: IDA } IDB } N1, 2. KDC S A: E(Ka, [Ks } IDB } N1 } E(Kb, [Ks } IDA])]), 3. A S B:, E(Kb, [Ks } IDA]) } E(Ks, M), This approach guarantees that only the intended recipient of a message will be, able to read it. It also provides a level of authentication that the sender is A. As, specified, the protocol does not protect against replays. Some measure of defense, could be provided by including a timestamp with the message. However, because, of the potential delays in the email process, such timestamps may have limited, usefulness., , 15.3 KERBEROS, Kerberos4 is an authentication service developed as part of Project Athena at MIT., The problem that Kerberos addresses is this: Assume an open distributed environment in which users at workstations wish to access services on servers distributed, throughout the network. We would like for servers to be able to restrict access to, authorized users and to be able to authenticate requests for service. In this environment, a workstation cannot be trusted to identify its users correctly to network, services. In particular, the following three threats exist:, 1. A user may gain access to a particular workstation and pretend to be another, user operating from that workstation., 2. A user may alter the network address of a workstation so that the requests, sent from the altered workstation appear to come from the impersonated, workstation., 3. A user may eavesdrop on exchanges and use a replay attack to gain entrance, to a server or to disrupt operations., In any of these cases, an unauthorized user may be able to gain access to services, and data that he or she is not authorized to access. Rather than building in elaborate, 4, , “In Greek mythology, a many headed dog, commonly three, perhaps with a serpent’s tail, the guardian, of the entrance of Hades.” From Dictionary of Subjects and Symbols in Art, by James Hall, Harper &, Row, 1979. Just as the Greek Kerberos has three heads, the modern Kerberos was intended to have three, components to guard a network’s gate: authentication, accounting, and audit. The last two heads were, never implemented.
Page 484 :
15.3 / KERBEROS, , 483, , authentication protocols at each server, Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users., Unlike most other authentication schemes described in this book, Kerberos relies, exclusively on symmetric encryption, making no use of public-key encryption., Two versions of Kerberos are in common use. Version 4 [MILL88, STEI88], implementations still exist. Version 5 [KOHL94] corrects some of the security deficiencies of version 4 and has been issued as a proposed Internet Standard (RFC, 4120 and RFC 4121).5, We begin this section with a brief discussion of the motivation for the Kerberos, approach. Then, because of the complexity of Kerberos, it is best to start with a description of the authentication protocol used in version 4. This enables us to see the, essence of the Kerberos strategy without considering some of the details required to, handle subtle security threats. Finally, we examine version 5., , Motivation, If a set of users is provided with dedicated personal computers that have no network, connections, then a user’s resources and files can be protected by physically securing each personal computer. When these users instead are served by a centralized, time-sharing system, the time-sharing operating system must provide the security., The operating system can enforce access-control policies based on user identity and, use the logon procedure to identify users., Today, neither of these scenarios is typical. More common is a distributed, architecture consisting of dedicated user workstations (clients) and distributed, or centralized servers. In this environment, three approaches to security can be, envisioned., 1. Rely on each individual client workstation to assure the identity of its user or, users and rely on each server to enforce a security policy based on user identification (ID)., 2. Require that client systems authenticate themselves to servers, but trust the, client system concerning the identity of its user., 3. Require the user to prove his or her identity for each service invoked. Also, require that servers prove their identity to clients., In a small, closed environment in which all systems are owned and operated, by a single organization, the first or perhaps the second strategy may suffice.6 But, in a more open environment in which network connections to other machines are, supported, the third approach is needed to protect user information and resources, housed at the server. Kerberos supports this third approach. Kerberos assumes a, distributed client/server architecture and employs one or more Kerberos servers to, provide an authentication service., , 5, , Versions 1 through 3 were internal development versions. Version 4 is the “original” Kerberos., However, even a closed environment faces the threat of attack by a disgruntled employee., , 6
Page 485 :
484, , CHAPTER 15 / USER AUTHENTICATION, , The first published report on Kerberos [STEI88] listed the following, requirements., ■, , ■, , ■, ■, , Secure: A network eavesdropper should not be able to obtain the necessary, information to impersonate a user. More generally, Kerberos should be strong, enough that a potential opponent does not find it to be the weak link., Reliable: For all services that rely on Kerberos for access control, lack of, availability of the Kerberos service means lack of availability of the supported, services. Hence, Kerberos should be highly reliable and should employ a, distributed server architecture with one system able to back up another., Transparent: Ideally, the user should not be aware that authentication is taking, place beyond the requirement to enter a password., Scalable: The system should be capable of supporting large numbers of clients, and servers. This suggests a modular, distributed architecture., , To support these requirements, the overall scheme of Kerberos is that of a, trusted third-party authentication service that uses a protocol based on that proposed by Needham and Schroeder [NEED78], which was discussed in Section 15.2., It is trusted in the sense that clients and servers trust Kerberos to mediate their, mutual authentication. Assuming the Kerberos protocol is well designed, then the, authentication service is secure if the Kerberos server itself is secure.7, , Kerberos Version 4, Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide the authentication service. Viewing the protocol as a whole, it is difficult to see, the need for the many elements contained therein. Therefore, we adopt a strategy, used by Bill Bryant of Project Athena [BRYA88] and build up to the full protocol, by looking first at several hypothetical dialogues. Each successive dialogue adds, additional complexity to counter security vulnerabilities revealed in the preceding, dialogue., After examining the protocol, we look at some other aspects of version 4., A SIMPLE AUTHENTICATION DIALOGUE In an unprotected network environment, any, client can apply to any server for service. The obvious security risk is that of impersonation. An opponent can pretend to be another client and obtain unauthorized privileges on server machines. To counter this threat, servers must be able to, confirm the identities of clients who request service. Each server can be required to, undertake this task for each client/server interaction, but in an open environment,, this places a substantial burden on each server., 7, , Remember that the security of the Kerberos server should not automatically be assumed but must be, guarded carefully (e.g., in a locked room). It is well to remember the fate of the Greek Kerberos, whom, Hercules was ordered by Eurystheus to capture as his Twelfth Labor: “Hercules found the great dog on its, chain and seized it by the throat. At once the three heads tried to attack, and Kerberos lashed about with, his powerful tail. Hercules hung on grimly, and Kerberos relaxed into unconsciousness. Eurystheus may, have been surprised to see Hercules alive—when he saw the three slavering heads and the huge dog they, belonged to he was frightened out of his wits, and leapt back into the safety of his great bronze jar.” From, The Hamlyn Concise Dictionary of Greek and Roman Mythology, by Michael Stapleton, Hamlyn, 1982.
Page 486 :
15.3 / KERBEROS, , 485, , An alternative is to use an authentication server (AS) that knows the, passwords of all users and stores these in a centralized database. In addition, the AS, shares a unique secret key with each server. These keys have been distributed physically or in some other secure manner. Consider the following hypothetical dialogue:, (1) C S AS:, IDC } PC } IDV, (2) AS S C:, Ticket, S, IDC } Ticket, (3) C V:, Ticket = E(Kv, [IDC } ADC } IDV]), where, C, AS, V, IDC, IDV, PC, ADC, Kv, , =, =, =, =, =, =, =, =, , client, authentication server, server, identifier of user on C, identifier of V, password of user on C, network address of C, secret encryption key shared by AS and V, , In this scenario, the user logs on to a workstation and requests access to server V., The client module C in the user’s workstation requests the user’s password and then, sends a message to the AS that includes the user’s ID, the server’s ID, and the user’s, password. The AS checks its database to see if the user has supplied the proper, password for this user ID and whether this user is permitted access to server V. If, both tests are passed, the AS accepts the user as authentic and must now convince, the server that this user is authentic. To do so, the AS creates a ticket that contains the user’s ID and network address and the server’s ID. This ticket is encrypted, using the secret key shared by the AS and this server. This ticket is then sent back, to C. Because the ticket is encrypted, it cannot be altered by C or by an opponent., With this ticket, C can now apply to V for service. C sends a message to V containing C’s ID and the ticket. V decrypts the ticket and verifies that the user ID in, the ticket is the same as the unencrypted user ID in the message. If these two match,, the server considers the user authenticated and grants the requested service., Each of the ingredients of message (3) is significant. The ticket is encrypted to, prevent alteration or forgery. The server’s ID (IDV) is included in the ticket so that, the server can verify that it has decrypted the ticket properly. IDC is included in the, ticket to indicate that this ticket has been issued on behalf of C. Finally, ADC serves, to counter the following threat. An opponent could capture the ticket transmitted, in message (2), then use the name IDC and transmit a message of form (3) from, another workstation. The server would receive a valid ticket that matches the user, ID and grant access to the user on that other workstation. To prevent this attack,, the AS includes in the ticket the network address from which the original request, came. Now the ticket is valid only if it is transmitted from the same workstation that, initially requested the ticket.
Page 487 :
486, , CHAPTER 15 / USER AUTHENTICATION, , A MORE SECURE AUTHENTICATION DIALOGUE Although the foregoing scenario solves, some of the problems of authentication in an open network environment, problems, remain. Two in particular stand out. First, we would like to minimize the number, of times that a user has to enter a password. Suppose each ticket can be used only, once. If user C logs on to a workstation in the morning and wishes to check his or her, mail at a mail server, C must supply a password to get a ticket for the mail server. If, C wishes to check the mail several times during the day, each attempt requires reentering the password. We can improve matters by saying that tickets are reusable., For a single logon session, the workstation can store the mail server ticket after it is, received and use it on behalf of the user for multiple accesses to the mail server., However, under this scheme, it remains the case that a user would need a new, ticket for every different service. If a user wished to access a print server, a mail, server, a file server, and so on, the first instance of each access would require a new, ticket and hence require the user to enter the password., The second problem is that the earlier scenario involved a plaintext transmission of the password [message (1)]. An eavesdropper could capture the password, and use any service accessible to the victim., To solve these additional problems, we introduce a scheme for avoiding plaintext passwords and a new server, known as the ticket-granting server (TGS). The, new (but still hypothetical) scenario is as follows., Once per user logon session:, (1) C S AS:, , IDC } IDtgs, , (2) AS S C:, , E(Kc, Ticket tgs), , Once per type of service:, (3) C S TGS: IDC } IDV } Ticket tgs, (4) TGS S C: Ticket v, Once per service session:, (5) C S V:, , IDC } Ticket v, , Ticket tgs = E(Ktgs, [IDC } ADC } IDtgs } TS1 } Lifetime1]), Ticket v = E(Kv, [IDC } ADC } IDv } TS2 } Lifetime2]), The new service, TGS, issues tickets to users who have been authenticated to, AS. Thus, the user first requests a ticket-granting ticket (Ticket tgs) from the AS. The, client module in the user workstation saves this ticket. Each time the user requires, access to a new service, the client applies to the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the particular service. The client saves, each service-granting ticket and uses it to authenticate its user to a server each time, a particular service is requested. Let us look at the details of this scheme:, 1. The client requests a ticket-granting ticket on behalf of the user by sending its, user’s ID to the AS, together with the TGS ID, indicating a request to use the, TGS service.
Page 488 :
15.3 / KERBEROS, , 487, , 2. The AS responds with a ticket that is encrypted with a key that is derived from, the user’s password (Kc), which is already stored at the AS. When this response, arrives at the client, the client prompts the user for his or her password, generates the key, and attempts to decrypt the incoming message. If the correct, password is supplied, the ticket is successfully recovered., Because only the correct user should know the password, only the correct user, can recover the ticket. Thus, we have used the password to obtain credentials from, Kerberos without having to transmit the password in plaintext. The ticket itself, consists of the ID and network address of the user, and the ID of the TGS. This, corresponds to the first scenario. The idea is that the client can use this ticket to, request multiple service-granting tickets. So the ticket-granting ticket is to be reusable. However, we do not wish an opponent to be able to capture the ticket and use, it. Consider the following scenario: An opponent captures the login ticket and waits, until the user has logged off his or her workstation. Then the opponent either gains, access to that workstation or configures his workstation with the same network address as that of the victim. The opponent would be able to reuse the ticket to spoof, the TGS. To counter this, the ticket includes a timestamp, indicating the date and, time at which the ticket was issued, and a lifetime, indicating the length of time for, which the ticket is valid (e.g., eight hours). Thus, the client now has a reusable ticket, and need not bother the user for a password for each new service request. Finally,, note that the ticket-granting ticket is encrypted with a secret key known only to the, AS and the TGS. This prevents alteration of the ticket. The ticket is reencrypted, with a key based on the user’s password. This assures that the ticket can be recovered only by the correct user, providing the authentication., Now that the client has a ticket-granting ticket, access to any server can be, obtained with steps 3 and 4., 3. The client requests a service-granting ticket on behalf of the user. For this purpose, the client transmits a message to the TGS containing the user’s ID, the, ID of the desired service, and the ticket-granting ticket., 4. The TGS decrypts the incoming ticket using a key shared only by the AS and, the TGS (Ktgs) and verifies the success of the decryption by the presence of its, ID. It checks to make sure that the lifetime has not expired. Then it compares, the user ID and network address with the incoming information to authenticate the user. If the user is permitted access to the server V, the TGS issues a, ticket to grant access to the requested service., The service-granting ticket has the same structure as the ticket-granting ticket., Indeed, because the TGS is a server, we would expect that the same elements are, needed to authenticate a client to the TGS and to authenticate a client to an application server. Again, the ticket contains a timestamp and lifetime. If the user wants, access to the same service at a later time, the client can simply use the previously, acquired service-granting ticket and need not bother the user for a password. Note, that the ticket is encrypted with a secret key (Kv) known only to the TGS and the, server, preventing alteration., Finally, with a particular service-granting ticket, the client can gain access to, the corresponding service with step 5., , Hiva-Network.Com
Page 489 :
488, , CHAPTER 15 / USER AUTHENTICATION, , 5. The client requests access to a service on behalf of the user. For this purpose, the, client transmits a message to the server containing the user’s ID and the servicegranting ticket. The server authenticates by using the contents of the ticket., This new scenario satisfies the two requirements of only one password query, per user session and protection of the user password., THE VERSION 4 AUTHENTICATION DIALOGUE Although the foregoing scenario enhances security compared to the first attempt, two additional problems remain. The, heart of the first problem is the lifetime associated with the ticket-granting ticket., If this lifetime is very short (e.g., minutes), then the user will be repeatedly asked, for a password. If the lifetime is long (e.g., hours), then an opponent has a greater, opportunity for replay. An opponent could eavesdrop on the network and capture, a copy of the ticket-granting ticket and then wait for the legitimate user to log out., Then the opponent could forge the legitimate user’s network address and send the, message of step (3) to the TGS. This would give the opponent unlimited access to, the resources and files available to the legitimate user., Similarly, if an opponent captures a service-granting ticket and uses it before it, expires, the opponent has access to the corresponding service., Thus, we arrive at an additional requirement. A network service (the TGS or, an application service) must be able to prove that the person using a ticket is the, same person to whom that ticket was issued., The second problem is that there may be a requirement for servers to authenticate themselves to users. Without such authentication, an opponent could sabotage the configuration so that messages to a server were directed to another location. The false server would then be in a position to act as a real server and capture, any information from the user and deny the true service to the user., We examine these problems in turn and refer to Table 15.1, which shows the, actual Kerberos protocol. Figure 15.2 provides a simplified overview., Table 15.1, , Summary of Kerberos Version 4 Message Exchanges, , (1) C S AS IDc } IDtgs } TS1, (2) AS S C E(Kc, [Kc, tgs } IDtgs } TS2 } Lifetime2 } Ticket tgs]), Ticket tgs = E(K tgs, [K c, tgs } IDC } ADC } IDtgs } TS2 } Lifetime 2]), (a) Authentication Service Exchange to obtain ticket-granting ticket, (3) C S TGS IDv } Ticket tgs } Authenticatorc, (4) TGS S C E(Kc, tgs, [Kc, v } IDv } TS4 } Ticket v]), Ticket tgs = E(K tgs, [K c, tgs } IDC } ADC } IDtgs } TS2 } Lifetime 2]), Ticket v = E(K v, [K c, v } IDC } ADC } IDv } TS4 } Lifetime 4]), Authenticatorc = E(K c, tgs, [IDC } ADC } TS3]), (b) Ticket-Granting Service Exchange to obtain service-granting ticket, (5) C S V Ticket v } Authenticatorc, (6) V S C E(Kc,v, [TS5 + 1]) (for mutual authentication), Ticket v = E(K v, [K c, v } IDC } ADC } IDv } TS4 } Lifetime 4]), Authenticatorc = E(K c, v, [IDC } ADC } TS5]), (c) Client/Server Authentication Exchange to obtain service
Page 490 :
15.3 / KERBEROS, 2. AS verifies user’s access right in, database, and creates ticket-granting ticket, and session key. Results are encrypted, using key derived from user’s password., , once per, user logon, session, , Kerberos, ket, t ticticket, s, e, u, req nting, gra, y, n ke, essio, s, +, t, ticke, servicerequest g ticket, n, ti, gran, , 1. User logs on to, workstation and, requests service on host, , ssion, ticket + se, , 3. Workstation prompts, user for password to decrypt, incoming message, and then, send ticket and, authenticator that contains, user’s name, network, address, and time to TGS., , 5. Workstation sends, ticket and authenticator, to host., , Figure 15.2, , 489, , key, , once per, type of service, , req, , ue, , st, , ser, , Authentication, server, Ticketgranting, server (TGS), 4. TGS decrypts ticket and, authenticator, verifies request,, and then creates ticket for, requested application server., , vic, , e, , pr, au ovid, the e s, nti erv, once per, ca er, tor, service session, , Host/, application, server, , 6. Host verifies that, ticket and authenticator, match, and then grants, access to service. If, mutual authentication is, required, server returns, an authenticator., , Overview of Kerberos, , First, consider the problem of captured ticket-granting tickets and the need, to determine that the ticket presenter is the same as the client for whom the ticket, was issued. The threat is that an opponent will steal the ticket and use it before it, expires. To get around this problem, let us have the AS provide both the client and, the TGS with a secret piece of information in a secure manner. Then the client can, prove its identity to the TGS by revealing the secret information—again in a secure, manner. An efficient way of accomplishing this is to use an encryption key as the, secure information; this is referred to as a session key in Kerberos., Table 15.1a shows the technique for distributing the session key. As before,, the client sends a message to the AS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from the user’s password, (Kc), that contains the ticket. The encrypted message also contains a copy of the, session key, Kc,tgs, where the subscripts indicate that this is a session key for C and, TGS. Because this session key is inside the message encrypted with Kc, only the, user’s client can read it. The same session key is included in the ticket, which can, be read only by the TGS. Thus, the session key has been securely delivered to both, C and the TGS.
Page 491 :
490, , CHAPTER 15 / USER AUTHENTICATION, , Note that several additional pieces of information have been added to this, first phase of the dialogue. Message (1) includes a timestamp, so that the AS knows, that the message is timely. Message (2) includes several elements of the ticket in a, form accessible to C. This enables C to confirm that this ticket is for the TGS and to, learn its expiration time., Armed with the ticket and the session key, C is ready to approach the TGS., As before, C sends the TGS a message that includes the ticket plus the ID of the, requested service [message (3) in Table 15.1b]. In addition, C transmits an authenticator, which includes the ID and address of C’s user and a timestamp. Unlike the ticket,, which is reusable, the authenticator is intended for use only once and has a very short, lifetime. The TGS can decrypt the ticket with the key that it shares with the AS. This, ticket indicates that user C has been provided with the session key Kc,tgs. In effect,, the ticket says, “Anyone who uses Kc,tgs must be C.” The TGS uses the session key to, decrypt the authenticator. The TGS can then check the name and address from the, authenticator with that of the ticket and with the network address of the incoming, message. If all match, then the TGS is assured that the sender of the ticket is indeed, the ticket’s real owner. In effect, the authenticator says, “At time TS3, I hereby use, Kc,tgs.” Note that the ticket does not prove anyone’s identity but is a way to distribute, keys securely. It is the authenticator that proves the client’s identity. Because the authenticator can be used only once and has a short lifetime, the threat of an opponent, stealing both the ticket and the authenticator for presentation later is countered., The reply from the TGS in message (4) follows the form of message (2). The, message is encrypted with the session key shared by the TGS and C and includes, a session key to be shared between C and the server V, the ID of V, and the timestamp of the ticket. The ticket itself includes the same session key., C now has a reusable service-granting ticket for V. When C presents this ticket,, as shown in message (5), it also sends an authenticator. The server can decrypt the, ticket, recover the session key, and decrypt the authenticator., If mutual authentication is required, the server can reply as shown in message, (6) of Table 15.1. The server returns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. C can decrypt this message to recover the incremented timestamp. Because the message was encrypted by, the session key, C is assured that it could have been created only by V. The contents, of the message assure C that this is not a replay of an old reply., Finally, at the conclusion of this process, the client and server share a secret, key. This key can be used to encrypt future messages between the two or to exchange a new random session key for that purpose., Figure 15.3 illustrates the Kerberos exchanges among the parties. Table 15.2, summarizes the justification for each of the elements in the Kerberos protocol., KERBEROS REALMS AND MULTIPLE KERBERI A full-service Kerberos environment, consisting of a Kerberos server, a number of clients, and a number of application, servers requires the following:, 1. The Kerberos server must have the user ID and hashed passwords of all participating users in its database. All users are registered with the Kerberos server., 2. The Kerberos server must share a secret key with each server. All servers are, registered with the Kerberos server.
Page 492 :
15.3 / KERBEROS, , Client, , Authentication, server (AS), , Ticket-granting, server (TGS), , 491, , Service, provider, , Client authentication, IDc || IDtgs || TS1, Shared key and ticket, E(Kc, [Kc, tgs || IDtgs || TS2 ||, Lifetime2 || Tickettgs]), Tickettgs, server ID, and client authentication, IDv || Tickettgs || Authenticatorc, Shared key and ticket, E(Kc,tgs, [Kc,v || IDv || TS4 || Ticketv]), Ticketv and client authentication, Ticketv || Authenticatorc, Service granted, E(Kc,v, [TS5 + 1]), , Figure 15.3, Table 15.2, , Kerberos Exchanges, , Rationale for the Elements of the Kerberos Version 4 Protocol, , Message (1), IDC, IDtgs, TS1, Message (2), Kc, , IDtgs, TS2, Lifetime2, , Client requests ticket-granting ticket., Tells AS identity of user from this client., Tells AS that user requests access to TGS., Allows AS to verify that client’s clock is synchronized with that of AS., AS returns ticket-granting ticket., Encryption is based on user’s password, enabling AS and client to verify password, and, protecting contents of message (2)., Copy of session key accessible to client created by AS to permit secure exchange between, client and TGS without requiring them to share a permanent key., Confirms that this ticket is for the TGS., Informs client of time this ticket was issued., Informs client of the lifetime of this ticket., , Ticket tgs, , Ticket to be used by client to access TGS., , Kc, tgs, , (a) Authentication Service Exchange, Message (3), IDV, Ticket tgs, Authenticatorc, , Client requests service-granting ticket., Tells TGS that user requests access to server V., Assures TGS that this user has been authenticated by AS., Generated by client to validate ticket., (Continued)
Page 493 :
492, , CHAPTER 15 / USER AUTHENTICATION, , Table 15.2, , Continued, , Message (4), Kc, tgs, Kc, v, , Kc, tgs, IDC, ADC, , TGS returns service-granting ticket., Key shared only by C and TGS protects contents of message (4)., Copy of session key accessible to client created by TGS to permit secure exchange between, client and server without requiring them to share a permanent key., Confirms that this ticket is for server V., Informs client of time this ticket was issued., Ticket to be used by client to access server V., Reusable so that user does not have to reenter password., Ticket is encrypted with key known only to AS and TGS, to prevent tampering., Copy of session key accessible to TGS used to decrypt authenticator, thereby authenticating, ticket., Indicates the rightful owner of this ticket., Prevents use of ticket from workstation other than one that initially requested the ticket., Assures server that it has decrypted ticket properly., Informs TGS of time this ticket was issued., Prevents replay after ticket has expired., Assures TGS that the ticket presenter is the same as the client for whom the ticket was, issued has very short lifetime to prevent replay., Authenticator is encrypted with key known only to client and TGS, to prevent tampering., Must match ID in ticket to authenticate ticket., Must match address in ticket to authenticate ticket., , TS3, , Informs TGS of time this authenticator was generated., , IDV, TS4, Ticket V, Ticket tgs, Ktgs, Kc, tgs, IDC, ADC, IDtgs, TS2, Lifetime2, Authenticatorc, , (b) Ticket-Granting Service Exchange, Message (5), Ticket V, Authenticatorc, Message (6), Kc, v, TS5 + 1, Ticket v, , Kc, v, IDC, ADC, , Client requests service., Assures server that this user has been authenticated by AS., Generated by client to validate ticket., Optional authentication of server to client., Assures C that this message is from V., Assures C that this is not a replay of an old reply., Reusable so that client does not need to request a new ticket from TGS for each access to, the same server., Ticket is encrypted with key known only to TGS and server, to prevent tampering., Copy of session key accessible to client; used to decrypt authenticator, thereby authenticating, ticket., Indicates the rightful owner of this ticket., Prevents use of ticket from workstation other than one that initially requested the ticket., Assures server that it has decrypted ticket properly., Informs server of time this ticket was issued., Prevents replay after ticket has expired., Assures server that the ticket presenter is the same as the client for whom the ticket was, issued; has very short lifetime to prevent replay., Authenticator is encrypted with key known only to client and server, to prevent tampering., Must match ID in ticket to authenticate ticket., Must match address in ticket to authenticate ticket., , TS5, , Informs server of time this authenticator was generated., , Kv, Kc, v, IDC, ADC, IDV, TS4, Lifetime4, Authenticatorc, , (c) Client/Server Authentication Exchange
Page 494 :
15.3 / KERBEROS, , 493, , Such an environment is referred to as a Kerberos realm. The concept of, realm can be explained as follows. A Kerberos realm is a set of managed nodes, that share the same Kerberos database. The Kerberos database resides on the, Kerberos master computer system, which should be kept in a physically secure, room. A read-only copy of the Kerberos database might also reside on other, Kerberos computer systems. However, all changes to the database must be, made on the master computer system. Changing or accessing the contents of a, Kerberos database requires the Kerberos master password. A related concept, is that of a Kerberos principal, which is a service or user that is known to the, Kerberos system. Each Kerberos principal is identified by its principal name., Principal names consist of three parts: a service or user name, an instance name,, and a realm name., Networks of clients and servers under different administrative organizations, typically constitute different realms. That is, it generally is not practical or does, not conform to administrative policy to have users and servers in one administrative domain registered with a Kerberos server elsewhere. However, users in one, realm may need access to servers in other realms, and some servers may be willing to provide service to users from other realms, provided that those users are, authenticated., Kerberos provides a mechanism for supporting such interrealm authentication., For two realms to support interrealm authentication, a third requirement is added:, 3. The Kerberos server in each interoperating realm shares a secret key with the, server in the other realm. The two Kerberos servers are registered with each, other., The scheme requires that the Kerberos server in one realm trust the Kerberos, server in the other realm to authenticate its users. Furthermore, the participating, servers in the second realm must also be willing to trust the Kerberos server in the, first realm., With these ground rules in place, we can describe the mechanism as follows, (Figure 15.4): A user wishing service on a server in another realm needs a ticket for, that server. The user’s client follows the usual procedures to gain access to the local, TGS and then requests a ticket-granting ticket for a remote TGS (TGS in another, realm). The client can then apply to the remote TGS for a service-granting ticket for, the desired server in the realm of the remote TGS., The details of the exchanges illustrated in Figure 15.4 are as follows (compare, Table 15.1)., (1) C S AS:, , IDc } IDtgs } TS1, , (2) AS S C:, , E(Kc, [Kc, tgs } IDtgs } TS2 } Lifetime2 } Ticket tgs]), , (3) C S TGS:, , IDtgsrem } Ticket tgs } Authenticatorc, , (4) TGS S C:, , E(Kc,tgs, [Kc, tgsrem } IDtgsrem } TS4 } Ticket tgsrem]), , (5) C S TGSrem: IDvrem } Ticket tgsrem } Authenticatorc, (6) TGSrem S C: E(Kc,tgsrem, [Kc, vrem } IDvrem } TS6 } Ticket vrem]), (7) C S Vrem:, , Ticket vrem } Authenticatorc
Page 495 :
CHAPTER 15 / USER AUTHENTICATION, , Realm A, , TGS, local, et for, k, c, i, S, t, l TG, quest, r loca, 1. Re, o, f, t, e, k, 2. Tic, , Kerberos, , Client, , 3. Request, , 4. Ticke, , ticket for re, mote, TGS, , t for rem, , ote TGS, , t, ver, ke, ser, tic er, ote, est erv, em, qu e s, rr, Re ot, 5. em, t fo, r, ke, for, Tic, 6., , 7. Request remote service, , 494, , Authentication, server (AS), Ticketgranting, server (TGS), , Kerberos, , Authentication, server (AS), Ticketgranting, server (TGS), , Host/, application, server, , Realm B, , Figure 15.4, , Request for Service in Another Realm, , The ticket presented to the remote server (Vrem) indicates the realm in which, the user was originally authenticated. The server chooses whether to honor the remote request., One problem presented by the foregoing approach is that it does not scale well, to many realms. If there are N realms, then there must be N(N - 1)/2 secure key, exchanges so that each Kerberos realm can interoperate with all other Kerberos, realms., , Kerberos Version 5, Kerberos version 5 is specified in RFC 4120 and provides a number of improvements over version 4 [KOHL94]. To begin, we provide an overview of the changes, from version 4 to version 5 and then look at the version 5 protocol.
Page 496 :
15.3 / KERBEROS, , 495, , DIFFERENCES BETWEEN VERSIONS 4 AND 5 Version 5 is intended to address the limitations of version 4 in two areas: environmental shortcomings and technical deficiencies. Let us briefly summarize the improvements in each area.8, Kerberos version 4 was developed for use within the Project Athena environment and, accordingly, did not fully address the need to be of general purpose. This, led to the following environmental shortcomings., 1. Encryption system dependence: Version 4 requires the use of DES. Export, restriction on DES as well as doubts about the strength of DES were thus of, concern. In version 5, ciphertext is tagged with an encryption-type identifier, so that any encryption technique may be used. Encryption keys are tagged, with a type and a length, allowing the same key to be used in different algorithms and allowing the specification of different variations on a given, algorithm., 2. Internet protocol dependence: Version 4 requires the use of Internet Protocol, (IP) addresses. Other address types, such as the ISO network address, are not, accommodated. Version 5 network addresses are tagged with type and length,, allowing any network address type to be used., 3. Message byte ordering: In version 4, the sender of a message employs a byte, ordering of its own choosing and tags the message to indicate least significant byte in lowest address or most significant byte in lowest address. This, techniques works but does not follow established conventions. In version, 5, all message structures are defined using Abstract Syntax Notation One, (ASN.1) and Basic Encoding Rules (BER), which provide an unambiguous, byte ordering., 4. Ticket lifetime: Lifetime values in version 4 are encoded in an 8-bit quantity, in units of five minutes. Thus, the maximum lifetime that can be expressed is, 28 * 5 = 1280 minutes (a little over 21 hours). This may be inadequate for, some applications (e.g., a long-running simulation that requires valid Kerberos, credentials throughout execution). In version 5, tickets include an explicit start, time and end time, allowing tickets with arbitrary lifetimes., 5. Authentication forwarding: Version 4 does not allow credentials issued to one, client to be forwarded to some other host and used by some other client. This, capability would enable a client to access a server and have that server access, another server on behalf of the client. For example, a client issues a request to, a print server that then accesses the client’s file from a file server, using the client’s credentials for access. Version 5 provides this capability., 6. Interrealm authentication: In version 4, interoperability among N realms, requires on the order of N2 Kerberos-to-Kerberos relationships, as described, earlier. Version 5 supports a method that requires fewer relationships, as described shortly., , 8, , The following discussion follows the presentation in [KOHL94].
Page 497 :
496, , CHAPTER 15 / USER AUTHENTICATION, , Apart from these environmental limitations, there are technical deficiencies, in the version 4 protocol itself. Most of these deficiencies were documented in, [BELL90], and version 5 attempts to address these. The deficiencies are the, following., 1. Double encryption: Note in Table 15.1 [messages (2) and (4)] that tickets provided to clients are encrypted twice—once with the secret key of the target, server and then again with a secret key known to the client. The second encryption is not necessary and is computationally wasteful., 2. PCBC encryption: Encryption in version 4 makes use of a nonstandard mode, of DES known as propagating cipher block chaining (PCBC).9 It has been, demonstrated that this mode is vulnerable to an attack involving the interchange of ciphertext blocks [KOHL89]. PCBC was intended to provide an integrity check as part of the encryption operation. Version 5 provides explicit, integrity mechanisms, allowing the standard CBC mode to be used for encryption. In particular, a checksum or hash code is attached to the message prior to, encryption using CBC., 3. Session keys: Each ticket includes a session key that is used by the client, to encrypt the authenticator sent to the service associated with that ticket., In addition, the session key may subsequently be used by the client and the, server to protect messages passed during that session. However, because, the same ticket may be used repeatedly to gain service from a particular, server, there is the risk that an opponent will replay messages from an old, session to the client or the server. In version 5, it is possible for a client, and server to negotiate a subsession key, which is to be used only for that, one connection. A new access by the client would result in the use of a new, subsession key., 4. Password attacks: Both versions are vulnerable to a password attack. The message from the AS to the client includes material encrypted with a key based, on the client’s password.10 An opponent can capture this message and attempt, to decrypt it by trying various passwords. If the result of a test decryption is of, the proper form, then the opponent has discovered the client’s password and, may subsequently use it to gain authentication credentials from Kerberos. This, is the same type of password attack described in Chapter 21, with the same, kinds of countermeasures being applicable. Version 5 does provide a mechanism known as preauthentication, which should make password attacks more, difficult, but it does not prevent them., THE VERSION 5 AUTHENTICATION DIALOGUE Table 15.3 summarizes the basic version 5 dialogue. This is best explained by comparison with version 4 (Table 15.1)., First, consider the authentication service exchange. Message (1) is a client request for a ticket-granting ticket. As before, it includes the ID of the user and the TGS., The following new elements are added:, , 9, , This is described in Appendix T., Appendix T describes the mapping of passwords to encryption keys., , 10, , Hiva-Network.Com
Page 498 :
15.3 / KERBEROS, Table 15.3, , 497, , Summary of Kerberos Version 5 Message Exchanges, , (1) C S AS Options } IDc } Realmc } IDtgs } Times } Nonce1, (2) AS S C RealmC } IDC } Ticket tgs } E(Kc, [Kc,tgs } Times } Nonce1 } Realmtgs } IDtgs]), Ticket tgs = E(Ktgs, [Flags } Kc,tgs } Realmc } IDC } ADC } Times]), (a) Authentication Service Exchange to obtain ticket-granting ticket, Options } IDv } Times } Nonce2 } Ticket tgs } Authenticatorc, , (3), , C S TGS, , (4), , TGS S C Realmc } IDC } Ticket v } E(Kc,tgs, [Kc,v } Times } Nonce2 } Realmv } IDv]), Ticket tgs = E(Ktgs, [Flags } Kc,tgs } Realmc } IDC } ADC } Times]), Ticket v = E(Kv, [Flags } Kc,v } Realmc } IDC } ADC } Times]), Authenticatorc = E(Kc,tgs, [IDC } Realmc } TS1]), (b) Ticket-Granting Service Exchange to obtain service-granting ticket, , (5) C S V Options } Ticket v } Authenticatorc, (6) V S C E Kc,v[TS2 } Subkey } Seq #], Ticket v = E(Kv, [Flag } Kc,v } Realmc } IDC } ADC } Times]), Authenticatorc = E(Kc,v, [IDC } Relamc } TS2 } Subkey } Seq #]), (c) Client/Server Authentication Exchange to obtain service, , ■, ■, ■, , ■, , Realm: Indicates realm of user, Options: Used to request that certain flags be set in the returned ticket, Times: Used by the client to request the following time settings in the ticket:, —from: the desired start time for the requested ticket, —till: the requested expiration time for the requested ticket, —rtime: requested renew-till time, Nonce: A random value to be repeated in message (2) to assure that the response is fresh and has not been replayed by an opponent, , Message (2) returns a ticket-granting ticket, identifying information for the, client, and a block encrypted using the encryption key based on the user’s password., This block includes the session key to be used between the client and the TGS,, times specified in message (1), the nonce from message (1), and TGS identifying, information. The ticket itself includes the session key, identifying information for, the client, the requested time values, and flags that reflect the status of this ticket, and the requested options. These flags introduce significant new functionality to, version 5. For now, we defer a discussion of these flags and concentrate on the overall structure of the version 5 protocol., Let us now compare the ticket-granting service exchange for versions, 4 and 5. We see that message (3) for both versions includes an authenticator, a, ticket, and the name of the requested service. In addition, version 5 includes requested times and options for the ticket and a nonce—all with functions similar, to those of message (1). The authenticator itself is essentially the same as the one, used in version 4.
Page 499 :
498, , CHAPTER 15 / USER AUTHENTICATION, , Message (4) has the same structure as message (2). It returns a ticket plus, information needed by the client, with the information encrypted using the session, key now shared by the client and the TGS., Finally, for the client/server authentication exchange, several new features, appear in version 5. In message (5), the client may request as an option that mutual, authentication is required. The authenticator includes several new fields:, ■, , ■, , Subkey: The client’s choice for an encryption key to be used to protect this, specific application session. If this field is omitted, the session key from the, ticket (Kc,v) is used., Sequence number: An optional field that specifies the starting sequence number to be used by the server for messages sent to the client during this session., Messages may be sequence numbered to detect replays., , If mutual authentication is required, the server responds with message (6)., This message includes the timestamp from the authenticator. Note that in version 4,, the timestamp was incremented by one. This is not necessary in version 5, because, the nature of the format of messages is such that it is not possible for an opponent to create message (6) without knowledge of the appropriate encryption keys., The subkey field, if present, overrides the subkey field, if present, in message (5)., The optional sequence number field specifies the starting sequence number to be, used by the client., TICKET FLAGS The flags field included in tickets in version 5 supports expanded, functionality compared to that available in version 4. Table 15.4 summarizes the, flags that may be included in a ticket., , Table 15.4, , Kerberos Version 5 Flags, , INITIAL, PRE-AUTHENT, HW-AUTHENT, RENEWABLE, MAY-POSTDATE, POSTDATED, INVALID, PROXIABLE, PROXY, FORWARDABLE, FORWARDED, , This ticket was issued using the AS protocol and not issued based on a, ticket-granting ticket., During initial authentication, the client was authenticated by the KDC, before a ticket was issued., The protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client., Tells TGS that this ticket can be used to obtain a replacement ticket that, expires at a later date., Tells TGS that a postdated ticket may be issued based on this ticketgranting ticket., Indicates that this ticket has been postdated; the end server can check the, authtime field to see when the original authentication occurred., This ticket is invalid and must be validated by the KDC before use., Tells TGS that a new service-granting ticket with a different network, address may be issued based on the presented ticket., Indicates that this ticket is a proxy., Tells TGS that a new ticket-granting ticket with a different network, address may be issued based on this ticket-granting ticket., Indicates that this ticket has either been forwarded or was issued based on, authentication involving a forwarded ticket-granting ticket.
Page 500 :
15.3 / KERBEROS, , 499, , The INITIAL flag indicates that this ticket was issued by the AS, not by the, TGS. When a client requests a service-granting ticket from the TGS, it presents a, ticket-granting ticket obtained from the AS. In version 4, this was the only way to, obtain a service-granting ticket. Version 5 provides the additional capability that, the client can get a service-granting ticket directly from the AS. The utility of this is, as follows: A server, such as a password-changing server, may wish to know that the, client’s password was recently tested., The PRE-AUTHENT flag, if set, indicates that when the AS received the initial request [message (1)], it authenticated the client before issuing a ticket. The, exact form of this preauthentication is left unspecified. As an example, the MIT, implementation of version 5 has encrypted timestamp preauthentication, enabled, by default. When a user wants to get a ticket, it has to send to the AS a preauthentication block containing a random confounder, a version number, and a timestamp, all encrypted in the client’s password-based key. The AS decrypts the block and will, not send a ticket-granting ticket back unless the timestamp in the preauthentication block is within the allowable time skew (time interval to account for clock drift, and network delays). Another possibility is the use of a smart card that generates, continually changing passwords that are included in the preauthenticated messages., The passwords generated by the card can be based on a user’s password but be, transformed by the card so that, in effect, arbitrary passwords are used. This prevents an attack based on easily guessed passwords. If a smart card or similar device, was used, this is indicated by the HW-AUTHENT flag., When a ticket has a long lifetime, there is the potential for it to be stolen and, used by an opponent for a considerable period. If a short lifetime is used to lessen, the threat, then overhead is involved in acquiring new tickets. In the case of a ticketgranting ticket, the client would either have to store the user’s secret key, which is, clearly risky, or repeatedly ask the user for a password. A compromise scheme is, the use of renewable tickets. A ticket with the RENEWABLE flag set includes two, expiration times: One for this specific ticket and one that is the latest permissible, value for an expiration time. A client can have the ticket renewed by presenting it, to the TGS with a requested new expiration time. If the new time is within the limit, of the latest permissible value, the TGS can issue a new ticket with a new session, time and a later specific expiration time. The advantage of this mechanism is that, the TGS may refuse to renew a ticket reported as stolen., A client may request that the AS provide a ticket-granting ticket with the, MAY-POSTDATE flag set. The client can then use this ticket to request a ticket, that is flagged as POSTDATED and INVALID from the TGS. Subsequently, the, client may submit the postdated ticket for validation. This scheme can be useful, for running a long batch job on a server that requires a ticket periodically. The, client can obtain a number of tickets for this session at once, with spread out time, values. All but the first ticket are initially invalid. When the execution reaches a, point in time when a new ticket is required, the client can get the appropriate ticket, validated. With this approach, the client does not have to repeatedly use its ticketgranting ticket to obtain a service-granting ticket., In version 5, it is possible for a server to act as a proxy on behalf of a client, in, effect adopting the credentials and privileges of the client to request a service from, another server. If a client wishes to use this mechanism, it requests a ticket-granting
Page 501 :
500, , CHAPTER 15 / USER AUTHENTICATION, , ticket with the PROXIABLE flag set. When this ticket is presented to the TGS, the, TGS is permitted to issue a service-granting ticket with a different network address;, this latter ticket will have its PROXY flag set. An application receiving such a ticket, may accept it or require additional authentication to provide an audit trail.11, The proxy concept is a limited case of the more powerful forwarding procedure., If a ticket is set with the FORWARDABLE flag, a TGS can issue to the requestor a, ticket-granting ticket with a different network address and the FORWARDED flag, set. This ticket then can be presented to a remote TGS. This capability allows a client to gain access to a server on another realm without requiring that each Kerberos, maintain a secret key with Kerberos servers in every other realm. For example,, realms could be structured hierarchically. Then a client could walk up the tree to a, common node and then back down to reach a target realm. Each step of the walk, would involve forwarding a ticket-granting ticket to the next TGS in the path., , 15.4 REMOTE USER-AUTHENTICATION USING, ASYMMETRIC ENCRYPTION, Mutual Authentication, In Chapter 14, we presented one approach to the use of public-key encryption for, the purpose of session-key distribution (Figure 14.9). This protocol assumes that, each of the two parties is in possession of the current public key of the other. It may, not be practical to require this assumption., A protocol using timestamps is provided in [DENN81]:, 1. A S AS: IDA } IDB, 2. AS S A: E(PRas, [IDA } PUa } T]) } E(PRas, [IDB } PUb } T]), 3. A S B:, E(PRas, [IDA } PUa } T]) } E(PRas, [IDB } PUb } T]) }, E(PUb, E(PRa, [Ks } T])), In this case, the central system is referred to as an authentication server (AS),, because it is not actually responsible for secret-key distribution. Rather, the AS provides public-key certificates. The session key is chosen and encrypted by A; hence,, there is no risk of exposure by the AS. The timestamps protect against replays of, compromised keys., This protocol is compact but, as before, requires the synchronization of clocks., Another approach, proposed by Woo and Lam [WOO92a], makes use of nonces., The protocol consists of the following steps., 1., 2., 3., 4., 5., 11, , A S KDC:, KDC S A:, A S B:, B S KDC:, KDC S B:, , IDA } IDB, E(PRauth, [IDB } PUb]), E(PUb, [Na } IDA]), IDA } IDB } E(PUauth, Na), E(PRauth, [IDA } PUa]) } E(PUb, E(PRauth, [Na } Ks } IDB])), , For a discussion of some of the possible uses of the proxy capability, see [NEUM93b].
Page 502 :
15.4 / REMOTE USER-AUTHENTICATION USING ASYMMETRIC ENCRYPTION, , 6. B S A:, 7. A S B:, , 501, , E(PUa, [E(PRauth, [(Na } Ks } IDB)]) } Nb]), E(Ks, Nb), , In step 1, A informs the KDC of its intention to establish a secure connection, with B. The KDC returns to A a copy of B’s public-key certificate (step 2). Using B’s, public key, A informs B of its desire to communicate and sends a nonce Na (step 3)., In step 4, B asks the KDC for A’s public-key certificate and requests a session key;, B includes A’s nonce so that the KDC can stamp the session key with that nonce., The nonce is protected using the KDC’s public key. In step 5, the KDC returns to, B a copy of A’s public-key certificate, plus the information {Na, Ks, IDB}. This information basically says that Ks is a secret key generated by the KDC on behalf of B, and tied to Na; the binding of Ks and Na will assure A that Ks is fresh. This triple is, encrypted using the KDC’s private key to allow B to verify that the triple is in fact, from the KDC. It is also encrypted using B’s public key so that no other entity may, use the triple in an attempt to establish a fraudulent connection with A. In step 6,, the triple {Na, Ks, IDB}, still encrypted with the KDC’s private key, is relayed to A,, together with a nonce Nb generated by B. All the foregoing are encrypted using A’s, public key. A retrieves the session key Ks, uses it to encrypt Nb, and returns it to B., This last message assures B of A’s knowledge of the session key., This seems to be a secure protocol that takes into account the various attacks., However, the authors themselves spotted a flaw and submitted a revised version of, the algorithm in [WOO92b]:, 1., 2., 3., 4., 5., , A S KDC:, KDC S A:, A S B:, B S KDC:, KDC S B:, 6. B S A:, 7. A S B:, , IDA } IDB, E(PRauth, [IDB } PUb]), E(PUb, [Na } IDA]), IDA } IDB } E(PUauth, Na), E(PRauth, [IDA } PUa]) } E(PUb, E(PRauth, [Na } Ks } IDA } IDB])), E(PUa, [Nb } E(PRauth, [Na } Ks } IDA } IDB])]), E(Ks, Nb), , The identifier of A, IDA, is added to the set of items encrypted with the KDC’s, private key in steps 5 and 6. This binds the session key Ks to the identities of the two, parties that will be engaged in the session. This inclusion of IDA accounts for the, fact that the nonce value Na is considered unique only among all nonces generated, by A, not among all nonces generated by all parties. Thus, it is the pair {IDA, Na}, that uniquely identifies the connection request of A., In both this example and the protocols described earlier, protocols that appeared secure were revised after additional analysis. These examples highlight the, difficulty of getting things right in the area of authentication., , One-Way Authentication, We have already presented public-key encryption approaches that are suited to, electronic mail, including the straightforward encryption of the entire message for, confidentiality (Figure 12.1b), authentication (Figure 12.1c), or both (Figure 12.1d)., These approaches require that either the sender know the recipient’s public key
Page 503 :
502, , CHAPTER 15 / USER AUTHENTICATION, , (confidentiality), the recipient know the sender’s public key (authentication), or, both (confidentiality plus authentication). In addition, the public-key algorithm, must be applied once or twice to what may be a long message., If confidentiality is the primary concern, then the following may be more efficient:, A S B: E(PUb, Ks) } E(Ks, M), In this case, the message is encrypted with a one-time secret key. A also encrypts this, one-time key with B’s public key. Only B will be able to use the corresponding private, key to recover the one-time key and then use that key to decrypt the message. This, scheme is more efficient than simply encrypting the entire message with B’s public key., If authentication is the primary concern, then a digital signature may suffice,, as was illustrated in Figure 13.2:, A S B: M } E(PRa, H(M)), This method guarantees that A cannot later deny having sent the message., However, this technique is open to another kind of fraud. Bob composes a message to his boss Alice that contains an idea that will save the company money. He, appends his digital signature and sends it into the email system. Eventually, the, message will get delivered to Alice’s mailbox. But suppose that Max has heard of, Bob’s idea and gains access to the mail queue before delivery. He finds Bob’s message, strips off his signature, appends his, and requeues the message to be delivered, to Alice. Max gets credit for Bob’s idea., To counter such a scheme, both the message and signature can be encrypted, with the recipient’s public key:, A S B: E(PUb, [M } E(PRa, H(M))]), The latter two schemes require that B know A’s public key and be convinced, that it is timely. An effective way to provide this assurance is the digital certificate,, described in Chapter 14. Now we have, A S B: M } E(PRa, H(M)) } E(PRas, [T } IDA } PUa]), In addition to the message, A sends B the signature encrypted with A’s private, key and A’s certificate encrypted with the private key of the authentication server., The recipient of the message first uses the certificate to obtain the sender’s public, key and verify that it is authentic and then uses the public key to verify the message, itself. If confidentiality is required, then the entire message can be encrypted with, B’s public key. Alternatively, the entire message can be encrypted with a one-time, secret key; the secret key is also transmitted, encrypted with B’s public key. This approach is explored in Chapter 19., , 15.5 FEDERATED IDENTITY MANAGEMENT, Federated identity management is a relatively new concept dealing with the use of, a common identity management scheme across multiple enterprises and numerous, applications and supporting many thousands, even millions, of users. We begin our, overview with a discussion of the concept of identity management and then examine, federated identity management.
Page 504 :
15.5 / FEDERATED IDENTITY MANAGEMENT, , 503, , Identity Management, Identity management is a centralized, automated approach to provide enterprisewide access to resources by employees and other authorized individuals. The focus, of identity management is defining an identity for each user (human or process),, associating attributes with the identity, and enforcing a means by which a user can, verify identity. The central concept of an identity management system is the use of, single sign-on (SSO)., SSO enables a user to access all network resources after a single authentication., Typical services provided by a federated identity management system include, the following:, ■, ■, ■, , ■, ■, ■, ■, , ■, , Point of contact: Includes authentication that a user corresponds to the user, name provided, and management of user/server sessions., SSO protocol services: Provides a vendor-neutral security token service for, supporting a single sign on to federated services., Trust services: Federation relationships require a trust relationship-based, federation between business partners. A trust relationship is represented by, the combination of the security tokens used to exchange information about a, user, the cryptographic information used to protect these security tokens, and, optionally the identity mapping rules applied to the information contained, within this token., Key services: Management of keys and certificates., Identity services: services that provide the interface to local data stores, including user registries and databases, for identity-related information management., Authorization: Granting access to specific services and/or resources based on, the authentication., Provisioning: Includes creating an account in each target system for the user,, enrollment or registration of user in accounts, establishment of access rights or, credentials to ensure the privacy and integrity of account data., Management: Services related to runtime configuration and deployment., , Note that Kerberos contains a number of the elements of an identity management system., Figure 15.5 illustrates entities and data flows in a generic identity management architecture. A principal is an identity holder. Typically, this is a human user, that seeks access to resources and services on the network. User devices, agent processes, and server systems may also function as principals. Principals authenticate, themselves to an identity provider. The identity provider associates authentication, information with a principal, as well as attributes and one or more identifiers., Increasingly, digital identities incorporate attributes other than simply an identifier and authentication information (such as passwords and biometric information)., An attribute service manages the creation and maintenance of such attributes. For, example, a user needs to provide a shipping address each time an order is placed at a, new Web merchant, and this information needs to be revised when the user moves., Identity management enables the user to provide this information once, so that it, is maintained in a single place and released to data consumers in accordance with
Page 505 :
504, , CHAPTER 15 / USER AUTHENTICATION, Identity, provider, , Data, consumer, , Principal, , Attribute, service, , Administrator, , Figure 15.5, , Generic Identity Management Architecture, , authorization and privacy policies. Users may create some of the attributes to be, associated with their digital identity, such as an address. Administrators may also assign attributes to users, such as roles, access permissions, and employee information., Data consumers are entities that obtain and employ data maintained and, provided by identity and attribute providers, which are often used to support authorization decisions and to collect audit information. For example, a database server, or file server is a data consumer that needs a client’s credentials so as to know what, access to provide to that client., , Identity Federation, Identity federation is, in essence, an extension of identity management to multiple, security domains. Such domains include autonomous internal business units, external business partners, and other third-party applications and services. The goal is to, provide the sharing of digital identities so that a user can be authenticated a single, time and then access applications and resources across multiple domains. Because, these domains are relatively autonomous or independent, no centralized control is, possible. Rather, the cooperating organizations must form a federation based on, agreed standards and mutual levels of trust to securely share digital identities., Federated identity management refers to the agreements, standards, and, technologies that enable the portability of identities, identity attributes, and entitlements across multiple enterprises and numerous applications and supporting many, thousands, even millions, of users. When multiple organizations implement interoperable federated identity schemes, an employee in one organization can use a single, sign-on to access services across the federation with trust relationships associated, with the identity. For example, an employee may log onto her corporate intranet, and be authenticated to perform authorized functions and access authorized services on that intranet. The employee could then access their health benefits from an, outside health-care provider without having to reauthenticate.
Page 506 :
15.5 / FEDERATED IDENTITY MANAGEMENT, , 505, , Beyond SSO, federated identity management provides other capabilities. One, is a standardized means of representing attributes. Increasingly, digital identities, incorporate attributes other than simply an identifier and authentication information (such as passwords and biometric information). Examples of attributes include, account numbers, organizational roles, physical location, and file ownership. A user, may have multiple identifiers; for example, each identifier may be associated with a, unique role with its own access permissions., Another key function of federated identity management is identity mapping., Different security domains may represent identities and attributes differently., Further, the amount of information associated with an individual in one domain, may be more than is necessary in another domain. The federated identity management protocols map identities and attributes of a user in one domain to the requirements of another domain., Figure 15.6 illustrates entities and data flows in a generic federated identity, management architecture., , User, , 1, Identity provider, (source domain), , 4, , 2, , Administrator, 3, , Service provider, (destination domain), , Figure 15.6, , Hiva-Network.Com, , 1, , End user’s browser or other application engages, in an authentication dialogue with identity provider, in the same domain. End user also provides attribute, values associated with user’s identity., , 2, , Some attributes associated with an identity, such as, allowable roles, may be provided by an administrator, in the same domain., , 3, , A service provider in a remote domain, which the user, wishes to access, obtains identity information,, authentication information, and associated attributes, from the identity provider in the source domain., , 4, , Service provider opens session with remote user and, enforces access control restrictions based on user’s, identity and attributes., , Federated Identity Operation
Page 507 :
506, , CHAPTER 15 / USER AUTHENTICATION, , The identity provider acquires attribute information through dialogue and protocol exchanges with users and administrators. For example, a user needs to provide, a shipping address each time an order is placed at a new Web merchant, and this, information needs to be revised when the user moves. Identity management enables, the user to provide this information once, so that it is maintained in a single place and, released to data consumers in accordance with authorization and privacy policies., Service providers are entities that obtain and employ data maintained and provided by identity providers, often to support authorization decisions and to collect, audit information. For example, a database server or file server is a data consumer, that needs a client’s credentials so as to know what access to provide to that client., A service provider can be in the same domain as the user and the identity provider., The power of this approach is for federated identity management, in which the service provider is in a different domain (e.g., a vendor or supplier network)., STANDARDS Federated identity management uses a number of standards as the, building blocks for secure identity exchange across different domains or heterogeneous systems. In essence, organizations issue some form of security tickets for their, users that can be processed by cooperating partners. Identity federation standards, are thus concerned with defining these tickets, in terms of content and format, providing protocols for exchanging tickets and performing a number of management, tasks. These tasks include configuring systems to perform attribute transfers and, identity mapping, and performing logging and auditing functions. The key standards are as follows:, ■, , ■, , ■, , ■, , The Extensible Markup Language (XML): A markup language that uses sets, of embedded tags or labels to characterize text elements within a document, so as to indicate their appearance, function, meaning, or context. XML documents appear similar to HTML (Hypertext Markup Language) documents, that are visible as Web pages, but provide greater functionality. XML includes, strict definitions of the data type of each field, thus supporting database formats and semantics. XML provides encoding rules for commands that are used, to transfer and update data objects., The Simple Object Access Protocol (SOAP): A minimal set of conventions, for invoking code using XML over HTTP. It enables applications to request, services from one another with XML-based requests and receive responses, as data formatted with XML. Thus, XML defines data objects and structures,, and SOAP provides a means of exchanging such data objects and performing, remote procedure calls related to these objects. See [ROS06] for an informative discussion., WS-Security: A set of SOAP extensions for implementing message integrity, and confidentiality in Web services. To provide for secure exchange of SOAP, messages among applications, WS-Security assigns security tokens to each, message for use in authentication., Security Assertion Markup Language (SAML): An XML-based language for, the exchange of security information between online business partners. SAML, conveys authentication information in the form of assertions about subjects., Assertions are statements about the subject issued by an authoritative entity.
Page 508 :
15.5 / FEDERATED IDENTITY MANAGEMENT, , 507, , The challenge with federated identity management is to integrate multiple, technologies, standards, and services to provide a secure, user-friendly utility. The, key, as in most areas of security and networking, is the reliance on a few mature, standards widely accepted by industry. Federated identity management seems to, have reached this level of maturity., EXAMPLES To get some feel for the functionality of identity federation, we look at, three scenarios, taken from [COMP06]., In the first scenario (Figure 15.7a), Workplace.com contracts with Health.com, to provide employee health benefits. An employee uses a Web interface to sign on to, Workplace.com and goes through an authentication procedure there. This enables, the employee to access authorized services and resources at Workplace.com. When, the employee clicks on a link to access health benefits, her browser is redirected to, Health.com. At the same time, the Workplace.com software passes the user’s identifier to Health.com in a secure manner. The two organizations are part of a federation, that cooperatively exchanges user identifiers. Health.com maintains user identities, , End user, (employee), , n, , n, , We, bsi, , o, ati, , tic, , n, the, Au, , End user, (employee), , te, , We, bsi, , o, ati, , tic, , n, the, Au, , acc, , ess, , User ID, , te, , acc, , ess, , Role, , Workplace.com, (employee portal), , Health.com, , User store, , User store, , Name, Joe, Jane, Ravi, , Name, Joe, Jane, Ravi, , ID, 1213, 1410, 1603, , ID, 1213, 1410, 1603, , Workplace.com, (employee portal), , PartsSupplier.com, , User store, , User store, Name, Joe, Jane, Ravi, , ID, 1213, 1410, 1603, , (a) Federation based on account linking, , Dept, Eng, Purch, Purch, , Role, Engineer, Purchaser, , (b) Federation based on roles, , End user, (employee), , n, tio, ica, ent, Au, rem t, u, c, s, Pro reque, nt, the, , SOAP message, , SOAP message, , Workplace.com, (procurement, application), , PinSupplies.com, (Purchasing Web, service), , (c) Chained Web services, , Figure 15.7 Federated Identity Scenarios, , Eship.com, (shipping Web, service)
Page 509 :
508, , CHAPTER 15 / USER AUTHENTICATION, , for every employee at Workplace.com and associates with each identity health-benefits information and access rights. In this example, the linkage between the two companies is based on account information and user participation is browser based., Figure 15.7b shows a second type of browser-based scheme. PartsSupplier., com is a regular supplier of parts to Workplace.com. In this case, a role-based, access-control (RBAC) scheme is used for access to information. An engineer of, Workplace.com authenticates at the employee portal at Workplace.com and clicks, on a link to access information at PartsSupplier.com. Because the user is authenticated in the role of an engineer, he is taken to the technical documentation and, troubleshooting portion of PartsSupplier.com’s Web site without having to sign on., Similarly, an employee in a purchasing role signs on at Workplace.com and is authorized, in that role, to place purchases at PartsSupplier.com without having to, authenticate to PartsSupplier.com. For this scenario, PartsSupplier.com does not, have identity information for individual employees at Workplace.com. Rather, the, linkage between the two federated partners is in terms of roles., The scenario illustrated in Figure 15.7c can be referred to as document based, rather than browser based. In this third example, Workplace.com has a purchasing, agreement with PinSupplies.com, and PinSupplies.com has a business relationship, with E-Ship.com. An employee of Workplace.com signs on and is authenticated to, make purchases. The employee goes to a procurement application that provides a, list of Workplace.com’s suppliers and the parts that can be ordered. The user clicks, on the PinSupplies button and is presented with a purchase order Web page (HTML, page). The employee fills out the form and clicks the submit button. The procurement application generates an XML/SOAP document that it inserts into the envelope body of an XML-based message. The procurement application then inserts the, user’s credentials in the envelope header of the message, together with Workplace., com’s organizational identity. The procurement application posts the message to, the PinSupplies.com’s purchasing Web service. This service authenticates the incoming message and processes the request. The purchasing Web service then sends, a SOAP message to its shipping partner to fulfill the order. The message includes, a PinSupplies.com security token in the envelope header and the list of items to be, shipped as well as the end user’s shipping information in the envelope body. The, shipping Web service authenticates the request and processes the shipment order., , 15.6 PERSONAL IDENTITY VERIFICATION, User authentication based on the possession of a smart card is becoming more widespread. A smart card has the appearance of a credit card, has an electronic interface, and may use a variety of authentication protocols., A smart card contains within it an entire microprocessor, including processor,, memory, and I/O ports. Some versions incorporate a special co-processing circuit, for cryptographic operation to speed the task of encoding and decoding messages or, generating digital signatures to validate the information transferred. In some cards,, the I/O ports are directly accessible by a compatible reader by means of exposed, electrical contacts. Other cards rely instead on an embedded antenna for wireless, communication with the reader.
Page 510 :
15.6 / PERSONAL IDENTITY VERIFICATION, , 509, , A typical smart card includes three types of memory. Read-only memory, (ROM) stores data that does not change during the card’s life, such as the card, number and the cardholder’s name. Electrically erasable programmable ROM, (EEPROM) holds application data and programs, such as the protocols that the, card can execute. It also holds data that may vary with time. For example, in a telephone card, the EEPROM holds the talk time remaining. Random access memory, (RAM) holds temporary data generated when applications are executed., For the practical application of smart card authentication, a wide range of, vendors must conform to standards that cover smart card protocols, authentication, and access control formats and protocols, database entries, message formats, and so, on. An important step in this direction is FIPS 201-2 (Personal Identity Verification, [PIV] of Federal Employees and Contractors, June 2012). The standard defines a, reliable, government-wide PIV system for use in applications such as access to federally controlled facilities and information systems. The standard specifies a PIV, system within which common identification credentials can be created and later, used to verify a claimed identity. The standard also identifies Federal governmentwide requirements for security levels that are dependent on risks to the facility or, information being protected. The standard applies to private-sector contractors as, well, and serves as a useful guideline for any organization., , PIV System Model, Figure 15.8 illustrates the major components of FIPS 201-2 compliant systems. The, PIV front end defines the physical interface to a user who is requesting access to a, facility, which could be either physical access to a protected physical area or logical, access to an information system. The PIV front-end subsystem supports up to threefactor authentication; the number of factors used depends on the level of security, required. The front end makes use of a smart card, known as a PIV card, which, is a dual-interface contact and contactless card. The card holds a cardholder photograph, X.509 certificates, cryptographic keys, biometric data, and a cardholder, unique identifier (CHUID). Certain cardholder information may be read-protected, and require a personal identification number (PIN) for read access by the card, reader. The biometric reader, in the current version of the standard, is a fingerprint, reader or an iris scanner., The standard defines three assurance levels for verification of the card and the, encoded data stored on the card, which in turn leads to verifying the authenticity of, the person holding the credential. A level of some confidence corresponds to use of, the card reader and PIN. A level of high confidence adds a biometric comparison, of a fingerprint captured and encoded on the card during the card-issuing process, and a fingerprint scanned at the physical access point. A very high confidence level, requires that the process just described is completed at a control point attended by, an official observer., The other major component of the PIV system is the PIV card issuance and, management subsystem. This subsystem includes the components responsible for, identity proofing and registration, card and key issuance and management, and the, various repositories and services (e.g., public key infrastructure [PKI] directory,, certificate status servers) required as part of the verification infrastructure.
Page 511 :
510, , CHAPTER 15 / USER AUTHENTICATION, , PIV card issuance, and management, Identity profiling, & registration, , Relying, PKI directory &, certificate status, responder, , Authorization, data, Physical Access Control, I&A, , Physical, resource, , Authorization, , Card issuance, & maintenance, Logical Access Control, , Key, management, , I&A, , Logical, resource, , Authorization, , Authorization, data, I&A = Identification and Authentication, , Card reader, /writer, , LEGEND, Shapes, Direction of information flow, , PIV card, , Processes, , PIN input, device, , Components, , Biometric, reader, , PIV Front End, , Figure 15.8 FIPS 201 PIV System Model, , The PIV system interacts with a relying subsystem, which includes components responsible for determining a particular PIV cardholder’s access to a physical, or logical resource. FIPS 201-2 standardizes data formats and protocols for interaction between the PIV system and the relying system., Unlike the typical card number/facility code encoded on most access control, cards, the FIPS 201 CHUID takes authentication to a new level, through the use of, an expiration date (a required CHUID data field) and an optional CHUID digital, signature. A digital signature can be checked to ensure that the CHUID recorded, on the card was digitally signed by a trusted source and that the CHUID data have, not been altered since the card was signed. The CHUID expiration date can be, checked to verify that the card has not expired. This is independent from whatever, expiration date is associated with cardholder privileges. Reading and verifying the, CHUID alone provides only some assurance of identity because it authenticates, the card data, not the cardholder. The PIN and biometric factors provide identity, verification of the individual., , PIV Documentation, The PIV specification is quite complex, and NIST has issued a number of documents that cover a broad range of PIV topics. These are as follows:
Page 512 :
15.6 / PERSONAL IDENTITY VERIFICATION, ■, , ■, , ■, , ■, , ■, , ■, , ■, , ■, , 511, , FIPS 201-2—Personal Identity Verification (PIV) of Federal Employees, and Contractors: Specifies the physical card characteristics, storage media,, and data elements that make up the identity credentials resident on the PIV, card., SP 800-73-3—Interfaces for Personal Identity Verification: Specifies the interfaces and card architecture for storing and retrieving identity credentials, from a smart card, and provides guidelines for the use of authentication mechanisms and protocols., SP 800-76-2—Biometric Data Specification for Personal Identity Verification:, Describes technical acquisition and formatting specifications for the biometric, credentials of the PIV system., SP 800-78-3—Cryptographic Algorithms and Key Sizes for Personal Identity, Verification: Identifies acceptable symmetric and asymmetric encryption algorithms, digital signature algorithms, and message digest algorithms, and specifies mechanisms to identify the algorithms associated with PIV keys or digital, signatures., SP 800-104—A Scheme for PIV Visual Card Topography: Provides additional, recommendations on the PIV card color-coding for designating employee, affiliation., SP 800-116—A Recommendation for the Use of PIV Credentials in Physical, Access Control Systems (PACS): Describes a risk-based approach for selecting appropriate PIV authentication mechanisms to manage physical access to, Federal government facilities and assets., SP 800-79-1—Guidelines for the Accreditation of Personal Identity, Verification Card Issuers: Provides guidelines for accrediting the reliability, of issuers of PIV cards that collect, store, and disseminate personal identity, credentials and issue smart cards., SP 800-96—PIV Card to Reader Interoperability Guidelines: Provides requirements that facilitate interoperability between any card and any reader., , In addition there are other documents that deal with conformance testing and, codes for identifiers., , PIV Credentials and Keys, The PIV card contains a number of mandatory and optional data elements that, serve as identity credentials with varying levels of strength and assurance. These, credentials are used singly or in sets to authenticate the holder of the PIV card to, achieve the level of assurance required for a particular activity or transaction. The, mandatory data elements are the following:, ■, ■, , Personal Identification Number (PIN): Required to activate the card for privileged operation., Cardholder Unique Identifier (CHUID): Includes the Federal Agency Smart, Credential Number (FASC-N) and the Global Unique Identification Number, (GUID), which uniquely identify the card and the cardholder.
Page 513 :
512, , CHAPTER 15 / USER AUTHENTICATION, ■, ■, ■, ■, , PIV Authentication Key: Asymmetric key pair and corresponding certificate, for user authentication., Two fingerprint templates: For biometric authentication., Electronic facial image: For biometric authentication., Asymmetric Card Authentication Key: Asymmetric key pair and corresponding certificate used for card authentication., Optional elements include the following:, , ■, ■, ■, ■, ■, , Digital Signature Key: Asymmetric key pair and corresponding certificate that, supports document signing and signing of data elements such as the CHUID., Key Management Key: Asymmetric key pair and corresponding certificate, supporting key establishment and transport., Symmetric Card Authentication Key: For supporting physical access applications., PIV Card Application Administration Key: Symmetric key associated with the, card management system., One or two iris images: For biometric authentication., Table 15.5 lists the algorithm and key size requirements for PIV key types., , Authentication, Using the electronic credentials resident on a PIV card, the card supports the following authentication mechanisms:, ■, , CHUID: The cardholder is authenticated using the signed CHUID data element on the card. The PIN is not required. This mechanism is useful in environments where a low level of assurance is acceptable and rapid contactless, authentication is necessary., , Table 15.5, , PIV Algorithms and Key Sizes, , PIV Key Type, , Algorithms, , Key Sizes (bits), , Application, , RSA, , 2048, , ECDSA, , 256, , Supports card and, cardholder authentication, for an interoperable, environment, , 3TDEA, , 168, , AES, , 128, 192, or 256, , RSA, , 2048, , ECDSA, , 256, , RSA, , 2048 or 3072, , ECDSA, , 256 or 384, , RSA, , 2048, , ECDH, , 256 or 384, , PIV Authentication Key, , Card Authentication Key, , Digital Signature Key, , Key Management Key, , Supports card authentication, for physical access, Supports card, authentication for an, interoperable environment, Supports document signing, and nonce signing, Supports key establishment, and transport
Page 514 :
15.6 / PERSONAL IDENTITY VERIFICATION, , 513, , ■, , Card Authentication Key: The PIV card is authenticated using the Card, Authentication Key in a challenge response protocol. The PIN is not required., This mechanism allows contact (via card reader) or contactless (via radio, waves) authentication of the PIV card without the holder’s active participation, and provides a low level of assurance., , ■, , BIO: The cardholder is authenticated by matching his or her fingerprint, sample(s) to the signed biometric data element in an environment without a, human attendant in view. The PIN is required to activate the card. This mechanism achieves a high level of assurance and requires the cardholder’s active, participation is submitting the PIN as well as the biometric sample., , ■, , BIO-A: The cardholder is authenticated by matching his or her fingerprint, sample(s) to the signed biometric data element in an environment with a, human attendant in view. The PIN is required to activate the card. This mechanism achieves a very high level of assurance when coupled with full trust validation of the biometric template retrieved from the card, and requires the, cardholder’s active participation is submitting the PIN as well as the biometric, sample., , ■, , PKI: The cardholder is authenticated by demonstrating control of the PIV authentication private key in a challenge response protocol that can be validated, using the PIV authentication certificate. The PIN is required to activate the, card. This mechanism achieves a very high level of identity assurance and requires the cardholder’s knowledge of the PIN., , In each of the above use cases, except the symmetric Card Authentication Key, use case, the source and the integrity of the corresponding PIV credential are validated by verifying the digital signature on the credential, with the signature being, provided by a trusted entity., A variety of protocols can be constructed for each of these authentication, types. SP 800-78-3 gives examples for each type. Figure 15.9 illustrates an authentication scenario that includes the use of the PIV Authentication Key. This scenario, provides a high level of assurance. This scenario would be appropriate for authentication of a user who possesses a PIV card and seeks access to a computer resource., The computer, designated local system in the figure, includes PIV application software and communicates to the card via an application program interface that enables the use of relatively high-level procedure calls. These high-level commands, are converted into PIV commands that are issued to the card through a physical, interface via a card reader or via a wireless interface. In either case, SP 800-73 refers, to the card command interface as the PIV card edge., The process begins when the local system detects the card either through an, attached card reader or wirelessly. It then selects an application on the card for authentication. The local system then requests the public-key certificate for the card’s, PIV Authentication Key. If the certificate is valid (i.e., has a valid signature, has not, expired or been revoked), authentication continues. Otherwise the card is rejected., The next step is for the local system to request that the cardholder enter the PIN, for the card. If the submitted PIN matches the PIN stored on the card, the card, returns a positive acknowledgment; otherwise the card returns a failure message.
Page 515 :
514, , CHAPTER 15 / USER AUTHENTICATION, , The local system either continues or rejects the card accordingly. The next phase is, a challenge-response protocol. The local system sends a nonce to be signed by the, PIV, and the PIV returns the signature. The local system uses the PIV authentication public key to verify the signature. If the signature is valid, the cardholder is accepted as being identified. Otherwise the local system rejects the card., The scenario of Figure 15.9 accomplishes three types of authentication. The, combination of possession of the card and knowledge of the PIN service authenticates the cardholder. The PIV Authentication Key certificate validates the card’s, credentials. The challenge-response protocol authenticates the card., , PIV Application, on Local System, , API on, Local System, , Present card, (HolderV), , PIV, Card Edge, , Connect, Begin transaction, Select application, Select application, PIV card app ID and Version, , Retrieve PIV, AUTH certificate, Validate certificate, (signature, expiration, and, revocation) (CredV), , Read value (PIV Auth certificate), , PIV Auth certificate returned, , Retrieve algorithm, ID and key size for, signature request, , Verify PIN, Acquire PIN, (HolderV), , Verify PIN, , PIN ACK, , Request card signature, Sign nonce, , Retrieve FASC-N, from the certificate, , Verify signed, data—card, possesses private, key (CardV), , Signed nonce returned, , End transaction, Disconnect, , Reject, , Cardholder identifier, , CardV = Card validation, CredV = Credential validation, HolderV = Cardholder validation, FASC-N = Federal Agency Smart Credential Number, , Figure 15.9 Authentication Using PIV Authentication Key, , Hiva-Network.Com
Page 516 :
15.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 515, , 15.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, authentication, authentication server, claimant, credential, credential service provider, (CSP), federated identity, management, identity management, , Kerberos, Kerberos realm, mutual authentication, nonce, one-way authentication, personal identity verification, (PIV), realm, registration authority (RA), , relying party (RP), replay attack, subscriber, suppress-replay attack, ticket, ticket-granting server (TGS), timestamp, verifier, , Review Questions, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 15.7, 15.8, 15.9, 15.10, , What are the steps involved in an authentication process?, List three general approaches to dealing with replay attacks., What is a suppress-replay attack?, What problem was Kerberos designed to address?, What are three threats associated with user authentication over a network or, Internet?, List three approaches to secure user authentication in a distributed environment., What four requirements were defined for Kerberos?, What entities constitute a full-service Kerberos environment?, In the context of Kerberos, what is a realm?, What are the mandatory elements to authenticate a PIV card holder?, , Problems, 15.1, , 15.2, , 15.3, , In Section 15.4, we outlined the public-key scheme proposed in [WOO92a] for the, distribution of secret keys. The revised version includes IDA in steps 5 and 6. What, attack, specifically, is countered by this revision?, The protocol referred to in Problem 15.1 can be reduced from seven steps to five,, having the following sequence:, a. A S B:, b. A S KDC:, c. KDC S B:, d. B S A:, e. A S B:, Show the message transmitted at each step. Hint: The final message in this protocol is, the same as the final message in the original protocol., Reference the suppress-replay attack described in Section 15.2 to answer the, following., a. Give an example of an attack when a party’s clock is ahead of that of the KDC., b. Give an example of an attack when a party’s clock is ahead of that of another, party.
Page 517 :
516, , CHAPTER 15 / USER AUTHENTICATION, 15.4, , There are three typical ways to use nonces as challenges. Suppose Na is a nonce generated by A, A and B share key K, and f() is a function (such as an increment). The, three usages are, Usage 1, , 15.5, 15.6, , 15.7, , Usage 2, , Usage 3, , (1) A S B: Na, , (1) A S B: E(K, Na), , (1) A S B: E(K, Na), , (2) B S A: E(K, Na), , (2) B S A: Na, , (2) B S A: E(K, f(Na)), , Describe situations for which each usage is appropriate., Show that a random error in one block of ciphertext is propagated to all subsequent, blocks of plaintext in PCBC mode (See Figure T.2 in Appendix T)., Suppose that, in PCBC mode, blocks Ci and Ci + 1 are interchanged during transmission. Show that this affects only the decrypted blocks Pi and Pi + 1 but not subsequent, blocks., In addition to providing a standard for public-key certificate formats, X.509 specifies, an authentication protocol. The original version of X.509 contains a security flaw., The essence of the protocol is as follows., A S B: A {t A, rA, IDB}, B S A: B {t B, rB, IDA, rA}, A S B: A {rB}, where t A and t B are timestamps, rA and rB are nonces and the notation X{Y} indicates, that the message Y is transmitted, encrypted, and signed by X., The text of X.509 states that checking timestamps t A and t B is optional for, three-way authentication. But consider the following example: Suppose A and B, have used the preceding protocol on some previous occasion, and that opponent C, has intercepted the preceding three messages. In addition, suppose that timestamps, are not used and are all set to 0. Finally, suppose C wishes to impersonate A to B. C, initially sends the first captured message to B:, C S B: A {0, rA, IDB}, B responds, thinking it is talking to A but is actually talking to C:, B S C: B {0, r B= , IDA, rA}, C meanwhile causes A to initiate authentication with C by some means. As a result,, A sends C the following:, =, A S C: A {0, r A, , IDC}, , C responds to A using the same nonce provided to C by B:, =, C S A: C {0, r B= , IDA, r A, }, , A responds with, A S C: A {r B= }
Page 518 :
15.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 517, , This is exactly what C needs to convince B that it is talking to A, so C now repeats the, incoming message back out to B., C S B: A {r B= }, , 15.8, , So B will believe it is talking to A whereas it is actually talking to C. Suggest a simple, solution to this problem that does not involve the use of timestamps., Consider a one-way authentication technique based on asymmetric encryption:, A S B: IDA, B S A: R1, A S B: E(PRa, R1), , 15.9, , a. Explain the protocol., b. What type of attack is this protocol susceptible to?, Consider a one-way authentication technique based on asymmetric encryption:, A S B: IDA| | E(PUB,RA), B S A: RA, , 15.10, 15.11, 15.12, 15.13, , a. Explain the protocol., b. What type of attack is this protocol susceptible to?, In Kerberos, when Bob receives a Ticket from Alice, how does he know it is not, genuine?, In Kerberos, how does Bob know that the received token is not corresponding to, Alice’s?, In Kerberos, how does Alice know that a reply to an earlier message is from Bob?, In Kerberos, what does the Ticket contain that allows Alice and Bob to talk securely?
Page 519 :
This page intentionally left blank, , M02_STAL4284_07_SE_C02.indd 46, , 7/26/16 3:53 PM
Page 520 :
PART SIX: NETWORK AND INTERNET SECURITY, CHAPTER, , Network Access Control, and Cloud Security, 16.1 Network Access Control, Elements of a Network Access Control System, Network Access Enforcement Methods, 16.2 Extensible Authentication Protocol, Authentication Methods, EAP Exchanges, 16.3 IEEE 802.1X Port-Based Network Access Control, 16.4 Cloud Computing, Cloud Computing Elements, Cloud Computing Reference Architecture, 16.5 Cloud Security Risks and Countermeasures, 16.6 Data Protection in the Cloud, 16.7 Cloud Security as a Service, 16.8 Addressing Cloud Computing Security Concerns, 16.9 Key Terms, Review Questions, and Problems, , 519
Page 521 :
520, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, , Discuss the principal elements of a network access control system., Discuss the principal network access enforcement methods., Present an overview of the Extensible Authentication Protocol., Understand the operation and role of the IEEE 802.1X Port-Based, Network Access Control mechanism., ◆ Present an overview of cloud computing concepts., ◆ Understand the unique security issues related to cloud computing., , This chapter begins our discussion of network security, focusing on two key topics:, network access control and cloud security. We begin with an overview of network, access control systems, summarizing the principal elements and techniques involved, in such a system. Next, we discuss the Extensible Authentication Protocol and IEEE, 802.1X, two widely implemented standards that are the foundation of many network, access control systems., The remainder of the chapter deals with cloud security. We begin with an, overview of cloud computing, and follow this with a discussion of cloud security, issues., , 16.1 NETWORK ACCESS CONTROL, Network access control (NAC) is an umbrella term for managing access to a, network. NAC authenticates users logging into the network and determines what, data they can access and actions they can perform. NAC also examines the health of, the user’s computer or mobile device (the endpoints)., , Elements of a Network Access Control System, NAC systems deal with three categories of components:, ■, , ■, , Access requestor (AR): The AR is the node that is attempting to access the, network and may be any device that is managed by the NAC system, including, workstations, servers, printers, cameras, and other IP-enabled devices. ARs are, also referred to as supplicants, or simply, clients., Policy server: Based on the AR’s posture and an enterprise’s defined policy,, the policy server determines what access should be granted. The policy server, often relies on backend systems, including antivirus, patch management, or a, user directory, to help determine the host’s condition.
Page 522 :
16.1 / NETWORK ACCESS CONTROL, ■, , 521, , Network access server (NAS): The NAS functions as an access control point, for users in remote locations connecting to an enterprise’s internal network., Also called a media gateway, a remote access server (RAS), or a policy server,, an NAS may include its own authentication services or rely on a separate, authentication service from the policy server., , Figure 16.1 is a generic network access diagram. A variety of different ARs, seek access to an enterprise network by applying to some type of NAS. The first, step is generally to authenticate the AR. Authentication typically involves some, sort of secure protocol and the use of cryptographic keys. Authentication may be, performed by the NAS, or the NAS may mediate the authentication process. In the, latter case, authentication takes place between the supplicant and an authentication, server that is part of the policy server or that is accessed by the policy server., The authentication process serves a number of purposes. It verifies a supplicant’s claimed identity, which enables the policy server to determine what access, privileges, if any, the AR may have. The authentication exchange may result in the, Supplicants, , Network access servers, Authentication, server, , DHCP, server, , VLAN, server, , Policy, server, , Patch, Antivirus Antispyware, management, , Network, resources, , Quarantine, network, , Enterprise network, Figure 16.1, , Network Access Control Context
Page 523 :
522, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , establishment of session keys to enable future secure communication between the, supplicant and resources on the enterprise network., Typically, the policy server or a supporting server will perform checks on the, AR to determine if it should be permitted interactive remote access connectivity., These checks—sometimes called health, suitability, screening, or assessment, checks—require software on the user’s system to verify compliance with certain, requirements from the organization’s secure configuration baseline. For example,, the user’s antimalware software must be up-to-date, the operating system must, be fully patched, and the remote computer must be owned and controlled by the, organization. These checks should be performed before granting the AR access to, the enterprise network. Based on the results of these checks, the organization can, determine whether the remote computer should be permitted to use interactive, remote access. If the user has acceptable authorization credentials but the remote, computer does not pass the health check, the user and remote computer should be, denied network access or have limited access to a quarantine network so that authorized personnel can fix the security deficiencies. Figure 16.1 indicates that the quarantine portion of the enterprise network consists of the policy server and related, AR suitability servers. There may also be application servers that do not require the, normal security threshold be met., Once an AR has been authenticated and cleared for a certain level of access, to the enterprise network, the NAS can enable the AR to interact with resources in, the enterprise network. The NAS may mediate every exchange to enforce a security, policy for this AR, or may use other methods to limit the privileges of the AR., , Network Access Enforcement Methods, Enforcement methods are the actions that are applied to ARs to regulate access, to the enterprise network. Many vendors support multiple enforcement methods, simultaneously, allowing the customer to tailor the configuration by using one or a, combination of methods. The following are common NAC enforcement methods., ■, , ■, , 1, , IEEE 802.1X: This is a link layer protocol that enforces authorization before, a port is assigned an IP address. IEEE 802.1X makes use of the Extensible, Authentication Protocol for the authentication process. Sections 16.2 and 16.3, cover the Extensible Authentication Protocol and IEEE 802.1X, respectively., Virtual local area networks (VLANs): In this approach, the enterprise network, consisting of an interconnected set of LANs, is segmented logically into, a number of virtual LANs.1 The NAC system decides to which of the network’s, VLANs it will direct an AR, based on whether the device needs security remediation, Internet access only, or some level of network access to enterprise, resources. VLANs can be created dynamically and VLAN membership, of, both enterprise servers and ARs, may overlap. That is, an enterprise server or, an AR may belong to more than one VLAN., , A VLAN is a logical subgroup within a LAN that is created via software rather than manually moving, cables in the wiring closet. It combines user stations and network devices into a single unit regardless, of the physical LAN segment they are attached to and allows traffic to flow more efficiently within, populations of mutual interest. VLANs are implemented in port-switching hubs and LAN switches.
Page 524 :
16.2 / EXTENSIBLE AUTHENTICATION PROTOCOL, ■, , ■, , 523, , Firewall: A firewall provides a form of NAC by allowing or denying network, traffic between an enterprise host and an external user. Firewalls are discussed, in Chapter 23., DHCP management: The Dynamic Host Configuration Protocol (DHCP) is, an Internet protocol that enables dynamic allocation of IP addresses to hosts., A DHCP server intercepts DHCP requests and assigns IP addresses instead., Thus, NAC enforcement occurs at the IP layer based on subnet and IP assignment. A DCHP server is easy to install and configure, but is subject to various, forms of IP spoofing, providing limited security., , There are a number of other enforcement methods available from vendors., The ones in the preceding list are perhaps the most common, and IEEE 802.1X is by, far the most commonly implemented solution., , 16.2 EXTENSIBLE AUTHENTICATION PROTOCOL, The Extensible Authentication Protocol (EAP), defined in RFC 3748, acts as a, framework for network access and authentication protocols. EAP provides a set of, protocol messages that can encapsulate various authentication methods to be used, between a client and an authentication server. EAP can operate over a variety of, network and link level facilities, including point-to-point links, LANs, and other, networks, and can accommodate the authentication needs of the various links and, networks. Figure 16.2 illustrates the protocol layers that form the context for EAP., , Authentication Methods, EAP supports multiple authentication methods. This is what is meant by referring, to EAP as extensible. EAP provides a generic transport service for the exchange of, authentication information between a client system and an authentication server., The basic EAP transport service is extended by using a specific authentication protocol, or method, that is installed in both the EAP client and the authentication server., EAPTLS, , EAPTTLS, , EAPPSK, , EAPIKEv2, , Other, , Authentication, methods, , Extensible Authentication Protocol (EAP), EAP, layer, IEEE 802.1X, EAP over LAN (EAPOL), , PPP, , Figure 16.2, , Hiva-Network.Com, , 802.3, Ethernet, , 802.11, WLAN, , Other, , EAP Layered Context, , Data link, layer
Page 525 :
524, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , Numerous methods have been defined to work over EAP. The following are, commonly supported EAP methods:, ■, , ■, , ■, , ■, , EAP-TLS (EAP Transport Layer Security): EAP-TLS (RFC 5216) defines, how the TLS protocol (described in Chapter 17) can be encapsulated in EAP, messages. EAP-TLS uses the handshake protocol in TLS, not its encryption, method. Client and server authenticate each other using digital certificates., Client generates a pre-master secret key by encrypting a random number with, the server’s public key and sends it to the server. Both client and server use the, pre-master to generate the same secret key., EAP-TTLS (EAP Tunneled TLS): EAP-TTLS is like EAP-TLS, except only, the server has a certificate to authenticate itself to the client first. As in EAPTLS, a secure connection (the “tunnel”) is established with secret keys, but, that connection is used to continue the authentication process by authenticating the client and possibly the server again using any EAP method or, legacy method such as PAP (Password Authentication Protocol) and CHAP, (Challenge-Handshake Authentication Protocol). EAP-TTLS is defined in, RFC 5281., EAP-GPSK (EAP Generalized Pre-Shared Key): EAP-GPSK, defined in, RFC 5433, is an EAP method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-GPSK specifies an EAP method, based on pre-shared keys and employs secret key-based cryptographic algorithms. Hence, this method is efficient in terms of message flows and computational costs, but requires the existence of pre-shared keys between each, peer and EAP server. The set up of these pairwise secret keys is part of the, peer registration, and thus, must satisfy the system preconditions. It provides, a protected communication channel when mutual authentication is successful for both parties to communicate over and is designed for authentication, over insecure networks such as IEEE 802.11. EAP-GPSK does not require, any public-key cryptography. The EAP method protocol exchange is done in a, minimum of four messages., EAP-IKEv2: It is based on the Internet Key Exchange protocol version 2, (IKEv2), which is described in Chapter 20. It supports mutual authentication, and session key establishment using a variety of methods. EAP-TLS is defined, in RFC 5106., , EAP Exchanges, Whatever method is used for authentication, the authentication information and, authentication protocol information are carried in EAP messages., RFC 3748 defines the goal of the exchange of EAP messages to be successful, authentication. In the context of RFC 3748, successful authentication is an exchange, of EAP messages, as a result of which the authenticator decides to allow access, by the peer, and the peer decides to use this access. The authenticator’s decision, typically involves both authentication and authorization aspects; the peer may, successfully authenticate to the authenticator, but access may be denied by the, authenticator due to policy reasons.
Page 526 :
16.2 / EXTENSIBLE AUTHENTICATION PROTOCOL, EAP authenticator, EAP peer, , Authentication server, (RADIUS), , Method, , Method, , EAP peer/, authenticator, , EAP, messages, , EAP layer, , Lower layer, , 802.1X,, PPP, , EAP, authenticator, EAP layer, , EAP, messages, , 525, , EAP peer/, authenticator, EAP layer, , Lower layer, , Lower layer, RADIUS, , Figure 16.3 EAP Protocol Exchanges, , Figure 16.3 indicates a typical arrangement in which EAP is used. The following components are involved:, ■, ■, ■, , EAP peer: Client computer that is attempting to access a network., EAP authenticator: An access point or NAS that requires EAP authentication, prior to granting access to a network., Authentication server: A server computer that negotiates the use of a specific, EAP method with an EAP peer, validates the EAP peer’s credentials, and, authorizes access to the network. Typically, the authentication server is a, Remote Authentication Dial-In User Service (RADIUS) server., , The authentication server functions as a backend server that can authenticate peers as a service to a number of EAP authenticators. The EAP authenticator then makes the decision of whether to grant access. This is referred to as the, EAP pass-through mode. Less commonly, the authenticator takes over the role of, the EAP server; that is, only two parties are involved in the EAP execution., As a first step, a lower-level protocol, such as PPP (point-to-point protocol), or IEEE 802.1X, is used to connect to the EAP authenticator. The software entity, in the EAP peer that operates at this level is referred to as the supplicant. EAP, messages containing the appropriate information for a chosen EAP method are, then exchanged between the EAP peer and the authentication server., EAP messages may include the following fields:, ■, ■, ■, , Code: Identifies the Type of EAP message. The codes are Request (1),, Response (2), Success (3), and Failure (4)., Identifier: Used to match Responses with Requests., Length: Indicates the length, in octets, of the EAP message, including the, Code, Identifier, Length, and Data fields.
Page 527 :
526, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, ■, , Data: Contains information related to authentication. Typically, the Data field, consists of a Type subfield, indicating the type of data carried, and a Type-Data, field., , The Success and Failure messages do not include a Data field., The EAP authentication exchange proceeds as follows. After a lower-level, exchange that established the need for an EAP exchange, the authenticator sends a, Request to the peer to request an identity, and the peer sends a Response with the, identity information. This is followed by a sequence of Requests by the authenticator and Responses by the peer for the exchange of authentication information. The, information exchanged and the number of Request–Response exchanges needed, depend on the authentication method. The conversation continues until either, (1) the authenticator determines that it cannot authenticate the peer and transmits, an EAP Failure or (2) the authenticator determines that successful authentication, has occurred and transmits an EAP Success., Figure 16.4 gives an example of an EAP exchange. Not shown in the figure is a, message or signal sent from the EAP peer to the authenticator using some protocol, other than EAP and requesting an EAP exchange to grant network access. One, protocol used for this purpose is IEEE 802.1X, discussed in the next section. The, first pair of EAP Request and Response messages is of Type identity, in which the, authenticator requests the peer’s identity, and the peer returns its claimed identity, in the Response message. This Response is passed through the authenticator to the, authentication server. Subsequent EAP messages are exchanged between the peer, and the authentication server., EAP authenticator, EAP peer, , Authentication server, (RADIUS), , EAP-Request/Identity, EAP-Response/Identity, , EAP-Request/Auth, EAP-Response/Auth, , EAP-Request/Auth, EAP-Response/Auth, , EAP-Success/Failure, , Figure 16.4, , EAP Message Flow in Pass-Through Mode
Page 528 :
16.3 / IEEE 802.1X PORT-BASED NETWORK ACCESS CONTROL, , 527, , Upon receiving the identity Response message from the peer, the server, selects an EAP method and sends the first EAP message with a Type field related, to an authentication method. If the peer supports and accepts the selected EAP, method, it replies with the corresponding Response message of the same type., Otherwise, the peer sends a NAK, and the EAP server either selects another EAP, method or aborts the EAP execution with a failure message. The selected EAP, method determines the number of Request/Response pairs. During the exchange, the appropriate authentication information, including key material, is exchanged., The exchange ends when the server determines that authentication has succeeded, or that no further attempt can be made and authentication has failed., , 16.3 IEEE 802.1X PORT-BASED NETWORK ACCESS CONTROL, IEEE 802.1X Port-Based Network Access Control was designed to provide access, control functions for LANs. Table 16.1 briefly defines key terms used in the IEEE, 802.11 standard. The terms supplicant, network access point, and authentication, Table 16.1 Terminology Related to IEEE 802.1X, Authenticator, An entity at one end of a point-to-point LAN segment that facilities authentication of the entity to the other, end of the link., Authentication exchange, The two-party conversation between systems performing an authentication process., Authentication process, The cryptographic operations and supporting data frames that perform the actual authentication., Authentication server (AS), An entity that provides an authentication service to an authenticator. This service determines, from the, credentials provided by supplicant, whether the supplicant is authorized to access the services provided by, the system in which the authenticator resides., Authentication transport, The datagram session that actively transfers the authentication exchange between two systems., Bridge port, A port of an IEEE 802.1D or 802.1Q bridge., Edge port, A bridge port attached to a LAN that has no other bridges attached to it., Network access port, A point of attachment of a system to a LAN. It can be a physical port, such as a single LAN MAC attached to, a physical LAN segment, or a logical port, for example, an IEEE 802.11 association between a station and an, access point., Port access entity (PAE), The protocol entity associated with a port. It can support the protocol functionality associated with the, authenticator, the supplicant, or both., Supplicant, An entity at one end of a point-to-point LAN segment that seeks to be authenticated by an authenticator, attached to the other end of that link.
Page 529 :
528, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , server correspond to the EAP terms peer, authenticator, and authentication server,, respectively., Until the AS authenticates a supplicant (using an authentication protocol),, the authenticator only passes control and authentication messages between the supplicant and the AS; the 802.1X control channel is unblocked, but the 802.11 data, channel is blocked. Once a supplicant is authenticated and keys are provided, the, authenticator can forward data from the supplicant, subject to predefined access, control limitations for the supplicant to the network. Under these circumstances,, the data channel is unblocked., As indicated in Figure 16.5, 802.1X uses the concepts of controlled and uncontrolled ports. Ports are logical entities defined within the authenticator and refer to, physical network connections. Each logical port is mapped to one of these two types, of physical ports. An uncontrolled port allows the exchange of protocol data units, (PDUs) between the supplicant and the AS, regardless of the authentication state, of the supplicant. A controlled port allows the exchange of PDUs between a supplicant and other systems on the network only if the current state of the supplicant, authorizes such an exchange., The essential element defined in 802.1X is a protocol known as EAPOL (EAP, over LAN). EAPOL operates at the network layers and makes use of an IEEE 802, LAN, such as Ethernet or Wi-Fi, at the link level. EAPOL enables a supplicant to, communicate with an authenticator and supports the exchange of EAP packets for, authentication., , Uncontrolled, port, Authentication server, , Network, access point, Supplicant, Controlled, port, , Network or Internet, , Figure 16.5, , 802.1X Access Control
Page 530 :
16.4 / CLOUD COMPUTING, Table 16.2, , 529, , Common EAPOL Frame Types, , Frame Type, , Definition, , EAPOL-EAP, , Contains an encapsulated EAP packet., , EAPOL-Start, , A supplicant can issue this packet instead of waiting for, a challenge from the authenticator., , EAPOL-Logoff, , Used to return the state of the port to unauthorized when, the supplicant is finished using the network., , EAPOL-Key, , Used to exchange cryptographic keying information., , The most common EAPOL packets are listed in Table 16.2. When the, supplicant first connects to the LAN, it does not know the MAC address of the, authenticator. Actually it doesn’t know whether there is an authenticator present, at all. By sending an EAPOL-Start packet to a special group-multicast address, reserved for IEEE 802.1X authenticators, a supplicant can determine whether an, authenticator is present and let it know that the supplicant is ready. In many cases,, the authenticator will already be notified that a new device has connected from some, hardware notification. For example, a hub knows that a cable is plugged in before, the device sends any data. In this case the authenticator may preempt the Start message with its own message. In either case the authenticator sends an EAP-Request, Identity message encapsulated in an EAPOL-EAP packet. The EAPOL-EAP is, the EAPOL frame type used for transporting EAP packets., The authenticator uses the EAP-Key packet to send cryptographic keys to the, supplicant once it has decided to admit it to the network. The EAP-Logoff packet, type indicates that the supplicant wishes to be disconnected from the network., The EAPOL packet format includes the following fields:, ■, ■, ■, ■, , Protocol version: version of EAPOL., Packet type: indicates start, EAP, key, logoff, etc., Packet body length: If the packet includes a body, this field indicates the body, length., Packet body: The payload for this EAPOL packet. An example is an EAP, packet., , Figure 16.6 shows an example of exchange using EAPOL. In Chapter 18, we, examine the use of EAP and EAPOL in the context of IEEE 802.11 wireless LAN, security., , 16.4 CLOUD COMPUTING, There is an increasingly prominent trend in many organizations to move a substantial portion of or even all information technology (IT) operations to an Internetconnected infrastructure known as enterprise cloud computing. This section provides, an overview of cloud computing. For a more detailed treatment, see [STAL16].
Page 531 :
530, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , EAP authenticator, EAP peer, , Authentication server, (RADIUS), , EAPOL-Start, EAPOL-EAP (EAP-Request/Identity), EAPOL-EAP (EAP-Response/Identity), EAPOL-EAP (EAP-Request/Auth), EAPOL-EAP (EAP-Response/Auth), , EAPOL-EAP (EAP-Request/Auth), EAPOL-EAP (EAP-Response/Auth), EAPOL-EAP (EAP-Success), , EAPOL-Logoff, , Figure 16.6, , Example Timing Diagram for IEEE 802.1X, , Cloud Computing Elements, NIST defines cloud computing, in NIST SP-800-145 (The NIST Definition of Cloud, Computing), as follows:, Cloud computing: A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks,, servers, storage, applications, and services) that can be rapidly provisioned and, released with minimal management effort or service provider interaction. This, cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models., The definition refers to various models and characteristics, whose relationship is, illustrated in Figure 16.7. The essential characteristics of cloud computing include, the following:, ■, , Broad network access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin
Page 532 :
Essential, Characteristics, , 16.4 / CLOUD COMPUTING, , Broad, Network Access, , Rapid, Elasticity, , Measured, Service, , 531, , On-Demand, Self-Service, , Resource Pooling, , Software as a Service (SaaS), Service, Models, , Platform as a Service (PaaS), , Deployment, Models, , Infrastructure as a Service (IaaS), , Public, , Private, , Hybrid, , Community, , Figure 16.7 Cloud Computing Elements, , ■, , ■, , ■, , ■, , or thick client platforms (e.g., mobile phones, laptops, and PDAs) as well as, other traditional or cloud-based software services., Rapid elasticity: Cloud computing gives you the ability to expand and reduce, resources according to your specific service requirement. For example, you, may need a large number of server resources for the duration of a specific task., You can then release these resources upon completion of the task., Measured service: Cloud systems automatically control and optimize resource, use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user, accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service., On-demand self-service: A consumer can unilaterally provision computing, capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider. Because, the service is on demand, the resources are not permanent parts of your IT, infrastructure., Resource pooling: The provider’s computing resources are pooled to serve, multiple consumers using a multi-tenant model, with different physical and, virtual resources dynamically assigned and reassigned according to consumer, demand. There is a degree of location independence in that the customer
Page 533 :
532, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , generally has no control or knowledge of the exact location of the provided, resources, but may be able to specify location at a higher level of abstraction, (e.g., country, state, or data center). Examples of resources include storage,, processing, memory, network bandwidth, and virtual machines. Even private, clouds tend to pool resources between different parts of the same organization., NIST defines three service models, which can be viewed as nested service, alternatives:, ■, , ■, , ■, , Software as a service (SaaS): The capability provided to the consumer is to use, the provider’s applications running on a cloud infrastructure. The applications, are accessible from various client devices through a thin client interface such as, a Web browser. Instead of obtaining desktop and server licenses for software, products it uses, an enterprise obtains the same functions from the cloud service., SaaS saves the complexity of software installation, maintenance, upgrades, and, patches. Examples of services at this level are Gmail, Google’s email service,, and Salesforce.com, which helps firms keep track of their customers., Platform as a service (PaaS): The capability provided to the consumer is to, deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. PaaS often provides middleware-style services such as database and, component services for use by applications. In effect, PaaS is an operating, system in the cloud., Infrastructure as a service (IaaS): The capability provided to the consumer is, to provision processing, storage, networks, and other fundamental computing, resources where the consumer is able to deploy and run arbitrary software,, which can include operating systems and applications. IaaS enables customers to combine basic computing services, such as number crunching and data, storage, to build highly adaptable computer systems., NIST defines four deployment models:, , ■, , ■, , ■, , ■, , Public cloud: The cloud infrastructure is made available to the general public, or a large industry group and is owned by an organization selling cloud services. The cloud provider is responsible both for the cloud infrastructure and, for the control of data and operations within the cloud., Private cloud: The cloud infrastructure is operated solely for an organization., It may be managed by the organization or a third party and may exist on premise or off premise. The cloud provider (CP) is responsible only for the infrastructure and not for the control., Community cloud: The cloud infrastructure is shared by several organizations, and supports a specific community that has shared concerns (e.g., mission, security, requirements, policy, and compliance considerations). It may be managed by the, organizations or a third party and may exist on premise or off premise., Hybrid cloud: The cloud infrastructure is a composition of two or more clouds, (private, community, or public) that remain unique entities but are bound, together by standardized or proprietary technology that enables data and, application portability (e.g., cloud bursting for load balancing between clouds)., , Hiva-Network.Com
Page 534 :
16.4 / CLOUD COMPUTING, , 533, , Enterprise, (Cloud user), LAN, switch, Router, , Router, , Network, or Internet, , Cloud, service, provider, LAN, switch, , Servers, , Figure 16.8, , Cloud Computing Context, , Figure 16.8 illustrates the typical cloud service context. An enterprise maintains workstations within an enterprise LAN or set of LANs, which are connected, by a router through a network or the Internet to the cloud service provider. The, cloud service provider maintains a massive collection of servers, which it manages with a variety of network management, redundancy, and security tools. In the, figure, the cloud infrastructure is shown as a collection of blade servers, which is a, common architecture., , Cloud Computing Reference Architecture, NIST SP 500-292 (NIST Cloud Computing Reference Architecture) establishes a, reference architecture, described as follows:, The NIST cloud computing reference architecture focuses on the requirements, of “what” cloud services provide, not a “how to” design solution and implementation. The reference architecture is intended to facilitate the understanding of, the operational intricacies in cloud computing. It does not represent the system, architecture of a specific cloud computing system; instead it is a tool for describing, discussing, and developing a system-specific architecture using a common, framework of reference.
Page 535 :
CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , Cloud provider, Service orchestration, Service layer, SaaS, , Cloud, auditor, Security, audit, Privacy, impact audit, , Service, intermediation, , PaaS, , Business, support, , IaaS, Resource abstraction, and control layer, , Provisioning/, configuration, , Physical resource layer, Hardware, , Performance, audit, , Cloud, broker, , Cloud, service, management, , Privacy, , Cloud, consumer, , Security, , 534, , Service, aggregation, Service, arbitrage, , Portability/, interoperability, , Facility, , Cloud carrier, Figure 16.9, , NIST Cloud Computing Reference Architecture, , NIST developed the reference architecture with the following objectives, in mind:, ■, ■, ■, , to illustrate and understand the various cloud services in the context of an, overall cloud computing conceptual model, to provide a technical reference for consumers to understand, discuss, categorize, and compare cloud services, to facilitate the analysis of candidate standards for security, interoperability,, and portability and reference implementations, , The reference architecture, depicted in Figure 16.9, defines five major actors, in terms of the roles and responsibilities:, ■, ■, ■, , ■, ■, , Cloud consumer: A person or organization that maintains a business relationship with, and uses service from, cloud providers., Cloud provider: A person, organization, or entity responsible for making a, service available to interested parties., Cloud auditor: A party that can conduct independent assessment of cloud, services, information system operations, performance, and security of the, cloud implementation., Cloud broker: An entity that manages the use, performance, and delivery of, cloud services, and negotiates relationships between CPs and cloud consumers., Cloud carrier: An intermediary that provides connectivity and transport of, cloud services from CPs to cloud consumers., , The roles of the cloud consumer and provider have already been discussed. To, summarize, a cloud provider can provide one or more of the cloud services to meet, IT and business requirements of cloud consumers. For each of the three service
Page 536 :
16.5 / CLOUD SECURITY RISKS AND COUNTERMEASURES, , 535, , models (SaaS, PaaS, IaaS), the CP provides the storage and processing facilities, needed to support that service model, together with a cloud interface for cloud, service consumers. For SaaS, the CP deploys, configures, maintains, and updates, the operation of the software applications on a cloud infrastructure so that the, services are provisioned at the expected service levels to cloud consumers. The, consumers of SaaS can be organizations that provide their members with access to, software applications, end users who directly use software applications, or software, application administrators who configure applications for end users., For PaaS, the CP manages the computing infrastructure for the platform and, runs the cloud software that provides the components of the platform, such as runtime software execution stack, databases, and other middleware components. Cloud, consumers of PaaS can employ the tools and execution resources provided by CPs to, develop, test, deploy, and manage the applications hosted in a cloud environment., For IaaS, the CP acquires the physical computing resources underlying the, service, including the servers, networks, storage, and hosting infrastructure. The, IaaS cloud consumer in turn uses these computing resources, such as a virtual, computer, for their fundamental computing needs., The cloud carrier is a networking facility that provides connectivity and transport of cloud services between cloud consumers and CPs. Typically, a CP will set up, service level agreements (SLAs) with a cloud carrier to provide services consistent, with the level of SLAs offered to cloud consumers, and may require the cloud carrier, to provide dedicated and secure connections between cloud consumers and CPs., A cloud broker is useful when cloud services are too complex for a cloud consumer to easily manage. Three areas of support can be offered by a cloud broker:, ■, ■, , ■, , Service intermediation: These are value-added services, such as identity management, performance reporting, and enhanced security., Service aggregation: The broker combines multiple cloud services to meet, consumer needs not specifically addressed by a single CP, or to optimize performance or minimize cost., Service arbitrage: This is similar to service aggregation except that the services, being aggregated are not fixed. Service arbitrage means a broker has the flexibility to choose services from multiple agencies. The cloud broker, for example, can, use a credit-scoring service to measure and select an agency with the best score., , A cloud auditor can evaluate the services provided by a CP in terms of security controls, privacy impact, performance, and so on. The auditor is an independent, entity that can assure that the CP conforms to a set of standards., , 16.5 CLOUD SECURITY RISKS AND COUNTERMEASURES, In general terms, security controls in cloud computing are similar to the security, controls in any IT environment. However, because of the operational models and, technologies used to enable cloud service, cloud computing may present risks that, are specific to the cloud environment. The essential concept in this regard is that, the enterprise loses a substantial amount of control over resources, services, and, applications but must maintain accountability for security and privacy policies.
Page 537 :
536, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , The Cloud Security Alliance [CSA10] lists the following as the top cloudspecific security threats, together with suggested countermeasures:, ■, , ■, , ■, , ■, , Abuse and nefarious use of cloud computing: For many CPs, it is relatively, easy to register and begin using cloud services, some even offering free limited, trial periods. This enables attackers to get inside the cloud to conduct various, attacks, such as spamming, malicious code attacks, and denial of service. PaaS, providers have traditionally suffered most from this kind of attacks; however,, recent evidence shows that hackers have begun to target IaaS vendors as well., The burden is on the CP to protect against such attacks, but cloud service clients must monitor activity with respect to their data and resources to detect, any malicious behavior., Countermeasures include (1) stricter initial registration and validation processes; (2) enhanced credit card fraud monitoring and coordination;, (3) comprehensive introspection of customer network traffic; and (4) monitoring public blacklists for one’s own network blocks., Insecure interfaces and APIs: CPs expose a set of software interfaces or APIs, that customers use to manage and interact with cloud services. The security, and availability of general cloud services are dependent upon the security of, these basic APIs. From authentication and access control to encryption and, activity monitoring, these interfaces must be designed to protect against both, accidental and malicious attempts to circumvent policy., Countermeasures include (1) analyzing the security model of CP interfaces; (2) ensuring that strong authentication and access controls are implemented in concert with encrypted transmission; and (3) understanding the, dependency chain associated with the API., Malicious insiders: Under the cloud computing paradigm, an organization, relinquishes direct control over many aspects of security and, in doing so, confers an unprecedented level of trust onto the CP. One grave concern is the, risk of malicious insider activity. Cloud architectures necessitate certain roles, that are extremely high risk. Examples include CP system administrators and, managed security service providers., Countermeasures include the following: (1) enforce strict supply chain, management and conduct a comprehensive supplier assessment; (2) specify, human resource requirements as part of legal contract; (3) require transparency into overall information security and management practices, as well as, compliance reporting; and (4) determine security breach notification processes., Shared technology issues: IaaS vendors deliver their services in a scalable way, by sharing infrastructure. Often, the underlying components that make up this, infrastructure (CPU caches, GPUs, etc.) were not designed to offer strong isolation properties for a multi-tenant architecture. CPs typically approach this, risk by the use of isolated virtual machines for individual clients. This approach, is still vulnerable to attack, by both insiders and outsiders, and so can only be a, part of an overall security strategy., Countermeasures include the following: (1) implement security best, practices for installation/configuration; (2) monitor environment for unauthorized changes/activity; (3) promote strong authentication and access control
Page 538 :
16.6 / DATA PROTECTION IN THE CLOUD, , ■, , ■, , ■, , 537, , for administrative access and operations; (4) enforce SLAs for patching and, vulnerability remediation; and (5) conduct vulnerability scanning and, configuration audits., Data loss or leakage: For many clients, the most devastating impact from a, security breach is the loss or leakage of data. We address this issue in the next, subsection., Countermeasures include the following: (1) implement strong API access control; (2) encrypt and protect integrity of data in transit; (3) analyze, data protection at both design and run time; and (4) implement strong key, generation, storage and management, and destruction practices., Account or service hijacking: Account or service hijacking, usually with stolen, credentials, remains a top threat. With stolen credentials, attackers can often, access critical areas of deployed cloud computing services, allowing them to, compromise the confidentiality, integrity, and availability of those services., Countermeasures include the following: (1) prohibit the sharing of, account credentials between users and services; (2) leverage strong two-factor, authentication techniques where possible; (3) employ proactive monitoring to detect unauthorized activity; and (4) understand CP security policies, and SLAs., Unknown risk profile: In using cloud infrastructures, the client necessarily, cedes control to the CP on a number of issues that may affect security. Thus, the client must pay attention to and clearly define the roles and responsibilities involved for managing risks. For example, employees may deploy applications and data resources at the CP without observing the normal policies and, procedures for privacy, security, and oversight., Countermeasures include (1) disclosure of applicable logs and data;, (2) partial/full disclosure of infrastructure details (e.g., patch levels and, firewalls); and (3) monitoring and alerting on necessary information., , Similar lists have been developed by the European Network and Information, Security Agency [ENIS09] and NIST [JANS11]., , 16.6 DATA PROTECTION IN THE CLOUD, As can be seen from the previous section, there are numerous aspects to cloud, security and numerous approaches to providing cloud security measures., A further example is seen in the NIST guidelines for cloud security, specified, in SP-800-14 and listed in Table 16.3. Thus, the topic of cloud security is well, beyond the scope of this chapter. In this section, we focus on one specific element, of cloud security., There are many ways to compromise data. Deletion or alteration of records, without a backup of the original content is an obvious example. Unlinking a record, from a larger context may render it unrecoverable, as can storage on unreliable, media. Loss of an encoding key may result in effective destruction. Finally, unauthorized parties must be prevented from gaining access to sensitive data.
Page 539 :
538, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , Table 16.3, , NIST Guidelines on Security and Privacy Issues and Recommendations, , Governance, Extend organizational practices pertaining to the policies, procedures, and standards used for application, development and service provisioning in the cloud, as well as the design, implementation, testing, use, and, monitoring of deployed or engaged services., Put in place audit mechanisms and tools to ensure organizational practices are followed throughout the, system life cycle., Compliance, Understand the various types of laws and regulations that impose security and privacy obligations on the, organization and potentially impact cloud computing initiatives, particularly those involving data location,, privacy and security controls, records management, and electronic discovery requirements., Review and assess the cloud provider’s offerings with respect to the organizational requirements to be met, and ensure that the contract terms adequately meet the requirements., Ensure that the cloud provider’s electronic discovery capabilities and processes do not compromise the, privacy or security of data and applications., Trust, Ensure that service arrangements have sufficient means to allow visibility into the security and privacy, controls and processes employed by the cloud provider, and their performance over time., Establish clear, exclusive ownership rights over data., Institute a risk management program that is flexible enough to adapt to the constantly evolving and, shifting risk landscape for the life cycle of the system., Continuously monitor the security state of the information system to support ongoing risk management, decisions., Architecture, Understand the underlying technologies that the cloud provider uses to provision services, including the, implications that the technical controls involved have on the security and privacy of the system, over the full, system life cycle and across all system components., Identity and access management, Ensure that adequate safeguards are in place to secure authentication, authorization, and other identity and, access management functions, and are suitable for the organization., Software isolation, Understand virtualization and other logical isolation techniques that the cloud provider employs in its, multi-tenant software architecture, and assess the risks involved for the organization., Data protection, Evaluate the suitability of the cloud provider’s data management solutions for the organizational data, concerned and the ability to control access to data, to secure data while at rest, in transit, and in use, and to, sanitize data., Take into consideration the risk of collating organizational data with those of other organizations whose, threat profiles are high or whose data collectively represent significant concentrated value., Fully understand and weigh the risks involved in cryptographic key management with the facilities, available in the cloud environment and the processes established by the cloud provider., Availability, Understand the contract provisions and procedures for availability, data backup and recovery, and disaster, recovery, and ensure that they meet the organization’s continuity and contingency planning requirements., Ensure that during an intermediate or prolonged disruption or a serious disaster, critical operations, can be immediately resumed, and that all operations can be eventually reinstituted in a timely and organized, manner., Incident response, Understand the contract provisions and procedures for incident response and ensure that they meet the, requirements of the organization.
Page 540 :
16.6 / DATA PROTECTION IN THE CLOUD, Table 16.3, , 539, , Continued, , Ensure that the cloud provider has a transparent response process in place and sufficient mechanisms to, share information during and after an incident., Ensure that the organization can respond to incidents in a coordinated fashion with the cloud provider in, accordance with their respective roles and responsibilities for the computing environment., , The threat of data compromise increases in the cloud, due to the number of, and interactions between risks and challenges that are either unique to the cloud or, more dangerous because of the architectural or operational characteristics of the, cloud environment., Database environments used in cloud computing can vary significantly. Some, providers support a multi-instance model, which provides a unique DBMS running, on a virtual machine instance for each cloud subscriber. This gives the subscriber, complete control over role definition, user authorization, and other administrative, tasks related to security. Other providers support a multi-tenant model, which provides a predefined environment for the cloud subscriber that is shared with other, tenants, typically through tagging data with a subscriber identifier. Tagging gives, the appearance of exclusive use of the instance, but relies on the CP to establish and, maintain a sound secure database environment., Data must be secured while at rest, in transit, and in use, and access to the, data must be controlled. The client can employ encryption to protect data in transit,, though this involves key management responsibilities for the CP. The client can, enforce access control techniques but, again, the CP is involved to some extent, depending on the service model used., For data at rest, the ideal security measure is for the client to encrypt the database and only store encrypted data in the cloud, with the CP having no access to the, encryption key. So long as the key remains secure, the CP has no ability to read the, data, although corruption and other denial-of-service attacks remain a risk., A straightforward solution to the security problem in this context is to encrypt, the entire database and not provide the encryption/decryption keys to the service, provider. This solution by itself is inflexible. The user has little ability to access, individual data items based on searches or indexing on key parameters, but rather, would have to download entire tables from the database, decrypt the tables, and, work with the results. To provide more flexibility, it must be possible to work with, the database in its encrypted form., An example of such an approach, depicted in Figure 16.10, is reported in, [DAMI05] and [DAMI03]. A similar approach is described in [HACI02]. Four entities are involved:, ■, ■, , ■, , Data owner: An organization that produces data to be made available for, controlled release, either within the organization or to external users., User: Human entity that presents requests (queries) to the system. The user, could be an employee of the organization who is granted access to the database via the server, or a user external to the organization who, after authentication, is granted access., Client: Frontend that transforms user queries into queries on the encrypted, data stored on the server.
Page 541 :
540, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , Metadata, , 1. Original query, , Metadata, , Database, , Data owner, 4. Plaintext, result, , User, Client, , Query, processor, , 2. Transformed, query, , Query, executor, , 3. Encrypted, result, , Metadata, , Encrypt/, Decrypt, , Cloud, server, , Encrypted, database, , Figure 16.10 An Encryption Scheme for a Cloud-Based Database, ■, , Server: An organization that receives the encrypted data from a data owner, and makes them available for distribution to clients. The server could in fact, be owned by the data owner but, more typically, is a facility owned and maintained by an external provider. For our discussion, the server is a cloud server., , Before continuing this discussion, we need to define some database terms., In relational database parlance, the basic building block is a relation, which is a flat, table. Rows are referred to as tuples, and columns are referred to as attributes., A primary key is defined to be a portion of a row used to uniquely identify a row in, a table; the primary key consists of one or more column names.2 For example, in, an employee table, the employee ID is sufficient to uniquely identify a row in a, particular table., Let us first examine the simplest possible arrangement based on this scenario., Suppose that each individual item in the database is encrypted separately, all using, the same encryption key. The encrypted database is stored at the server, but the, server does not have the encryption key. Thus, the data are secure at the server., Even if someone were able to hack into the server’s system, all he or she would have, access to is encrypted data. The client system does have a copy of the encryption, key. A user at the client can retrieve a record from the database with the following, sequence:, 1. The user issues a query for fields from one or more records with a specific, value of the primary key., 2, Note that a primary key has nothing to do with cryptographic keys. A primary key in a database is a, means of indexing into the database.
Page 542 :
16.7 / CLOUD SECURITY AS A SERVICE, , 541, , 2. The query processor at the client encrypts the primary key, modifies the query, accordingly, and transmits the query to the server., 3. The server processes the query using the encrypted value of the primary key, and returns the appropriate record or records., 4. The query processor decrypts the data and returns the results., This method is certainly straightforward but is quite limited. For example, suppose the Employee table contains a salary attribute and the user wishes to retrieve, all records for salaries less than $70K. There is no obvious way to do this, because, the attribute value for salary in each record is encrypted. The set of encrypted values, does not preserve the ordering of values in the original attribute., There are a number of ways to extend the functionality of this approach. For, example, an unencrypted index value can be associated with a given attribute and, the table can be partitioned based on these index values, enabling a user to retrieve, a certain portion of the table. The details of such schemes are beyond our scope., See [STAL15] for more detail., , 16.7 CLOUD SECURITY AS A SERVICE, The term Security as a Service (SecaaS) has generally meant a package of security, services offered by a service provider that offloads much of the security responsibility from an enterprise to the security service provider. Among the services, typically provided are authentication, antivirus, antimalware/-spyware, intrusion, detection, and security event management. In the context of cloud computing,, cloud security as a service, designated SecaaS, is a segment of the SaaS offering, of a CP., The Cloud Security Alliance defines SecaaS as the provision of security, applications and services via the cloud either to cloud-based infrastructure and software or from the cloud to the customers’ on-premise systems [CSA11b]. The Cloud, Security Alliance has identified the following SecaaS categories of service:, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, , Identity and access management, Data loss prevention, Web security, Email security, Security assessments, Intrusion management, Security information and event management, Encryption, Business continuity and disaster recovery, Network security, , In this section, we examine these categories with a focus on security of the, cloud-based infrastructure and services (Figure 16.11)., , Hiva-Network.Com
Page 543 :
542, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , Encryption, , Email security, Data loss, prevention, , Security assessments, Security information and, event management, Business continuity and, disaster recovery, , Web security, Intrusion, management, , Identity and access management, Network security, , Cloud service clients and adversaries, , Figure 16.11, , Elements of Cloud Security as a Service, , Identity and access management (IAM) includes people, processes, and, systems that are used to manage access to enterprise resources by assuring that the, identity of an entity is verified, and then granting the correct level of access based, on this assured identity. One aspect of identity management is identity provisioning, which has to do with providing access to identified users and subsequently, deprovisioning, or deny access, to users when the client enterprise designates such, users as no longer having access to enterprise resources in the cloud. Another aspect, of identity management is for the cloud to participate in the federated identity management scheme (see Chapter 15) scheme used by the client enterprise. Among, other requirements, the cloud service provider (CSP) must be able to exchange, identity attributes with the enterprise’s chosen identity provider., The access management portion of IAM involves authentication and access, control services. For example, the CSP must be able to authenticate users in a, trustworthy manner. The access control requirements in SPI environments include, establishing trusted user profile and policy information, using it to control access, within the cloud service, and doing this in an auditable way., Data loss prevention (DLP) is the monitoring, protecting, and verifying the, security of data at rest, in motion, and in use. Much of DLP can be implemented by
Page 544 :
16.7 / CLOUD SECURITY AS A SERVICE, , 543, , the cloud client, such as discussed in Section 16.6. The CSP can also provide DLP, services, such as implementing rules about what functions can be performed on data, in various contexts., Web security is real-time protection offered either on premise through software/appliance installation or via the cloud by proxying or redirecting Web traffic, to the CP. This provides an added layer of protection on top of things like antiviruses to prevent malware from entering the enterprise via activities such as Web, browsing. In addition to protecting against malware, a cloud-based Web security, service might include usage policy enforcement, data backup, traffic control, and, Web access control., A CSP may provide a Web-based email service, for which security measures, are needed. Email security provides control over inbound and outbound email,, protecting the organization from phishing, malicious attachments, enforcing corporate polices such as acceptable use and spam prevention. The CSP may also incorporate digital signatures on all email clients and provide optional email encryption., Security assessments are third-part audits of cloud services. While this service, is outside the province of the CSP, the CSP can provide tools and access points to, facilitate various assessment activities., Intrusion management encompasses intrusion detection, prevention, and, response. The core of this service is the implementation of intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) at entry points to the cloud, and on servers in the cloud. An IDS is a set of automated tools designed to detect, unauthorized access to a host system. We discuss this in Chapter 21. An IPS incorporates IDS functionality but also includes mechanisms designed to block traffic, from intruders., Security information and event management (SIEM) aggregates (via push or, pull mechanisms) log and event data from virtual and real networks, applications,, and systems. This information is then correlated and analyzed to provide real-time, reporting and alerting on information/events that may require intervention or other, type of response. The CSP typically provides an integrated service that can put, together information from a variety of sources both within the cloud and within the, client enterprise network., Encryption is a pervasive service that can be provided for data at rest in the, cloud, email traffic, client-specific network management information, and identity, information. Encryption services provided by the CSP involve a range of complex, issues, including key management, how to implement virtual private network (VPN), services in the cloud, application encryption, and data content access., Business continuity and disaster recovery comprise measures and mechanisms, to ensure operational resiliency in the event of any service interruptions. This is, an area where the CSP, because of economies of scale, can offer obvious benefits, to a cloud service client [WOOD10]. The CSP can provide backup at multiple, locations, with reliable failover and disaster recovery facilities. This service must, include a flexible infrastructure, redundancy of functions and hardware, monitored, operations, geographically distributed data centers, and network survivability., Network security consists of security services that allocate access, distribute,, monitor, and protect the underlying resource services. Services include perimeter, and server firewalls and denial-of-service protection. Many of the other services
Page 545 :
544, , CHAPTER 16 / NETWORK ACCESS CONTROL AND CLOUD SECURITY, , listed in this section, including intrusion management, identity and access management, data loss protection, and Web security, also contribute to the network, security service., , 16.8 ADDRESSING CLOUD COMPUTING SECURITY CONCERNS, Numerous documents have been developed to guide businesses thinking about the, security issues associated with cloud computing. In addition to SP 800-144, which, provides overall guidance, NIST has issued SP 800-146 (Cloud Computing Synopsis, and Recommendations, May 2012). NIST’s recommendations systematically consider each of the major types of cloud services consumed by businesses including, Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as, a Service (PaaS). While security issues vary somewhat depending on the type of, cloud service, there are multiple NIST recommendations that are independent of, service type. Not surprisingly, NIST recommends selecting cloud providers that, support strong encryption, have appropriate redundancy mechanisms in place,, employ authentication mechanisms, and offer subscribers sufficient visibility about, mechanisms used to protect subscribers from other subscribers and the provider., SP 800-146 also lists the overall security controls that are relevant in a cloud computing environment and that must be assigned to the different cloud actors. These, are shown in Table 16.4., As more businesses incorporate cloud services into their enterprise network infrastructures, cloud computing security will persist as an important issue., Examples of cloud computing security failures have the potential to have a chilling, effect on business interest in cloud services and this is inspiring service providers, to be serious about incorporating security mechanisms that will allay concerns of, potential subscribers. Some service providers have moved their operations to Tier 4, data centers to address user concerns about availability and redundancy. Because so, many businesses remain reluctant to embrace cloud computing in a big way, cloud, service providers will have to continue to work hard to convince potential customers, that computing support for core business processes and mission critical applications, can be moved safely and securely to the cloud., Table 16.4, , Control Functions and Classes, Technical, , Access Control, Audit and Accountability, Identification and Authentication, System and Communication, Protection, , Operational, Awareness and Training, Configuration and Management, Contingency Planning, Incident Response, Maintenance, Media Protection, Physical and Environmental, Protection, Personnel Security System and, Information Integrity, , Management, Certification, Accreditation, and, Security Assessment, Planning Risk Assessment, System and Services Acquisition
Page 546 :
16.9 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 545, , 16.9 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, access requestor (AR), authentication server, cloud, cloud auditor, cloud broker, cloud carrier, cloud computing, cloud consumer, cloud provider, community cloud, Dynamic Host Configuration, Protocol (DHCP), EAP authenticator, EAP-GPSK, , EAP-IKEv2, EAP over LAN (EAPOL), EAP method, EAP pass-through mode, EAP peer, EAP-TLS, EAP-TTLS, Extensible Authentication, Protocol (EAP), firewall, IEEE 802.1X, media gateway, Network Access Control, (NAC), , Network Access Server, (NAS), Platform as a Service (PaaS), policy server, private cloud, public cloud, Remote Access Server (RAS), Security as a Service (SecaaS), Software as a Service (SaaS), supplicant, Virtual Local Area Network, (VLAN), , Review Questions, 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 16.7, 16.8, 16.9, , Provide a brief definition of network access control., What is an EAP?, List and briefly define four EAP authentication methods., What is DHCP? How useful is it to help achieve security of IP addresses?, Why is EAPOL an essential element of IEEE 802.1X?, What are the essential characteristics of cloud computing?, List and briefly define the deployment models of cloud computing., What is the cloud computing reference architecture?, Describe some of the main cloud-specific security threats., , Problems, 16.1, 16.2, , 16.3, , Investigate the network access control scheme used at your school or place of, employment. Draw a diagram and describe the principal components., Figure 16.3 suggests that EAP can be described in the context of a four-layer model., Indicate the functions and formats of each of the four layers. You may need to refer, to RFC 3748., List some commonly used cloud-based data services. Explore and compare these, services based on their use of encryption, flexibility, efficiency, speed, and ease of use., Study security breaches on these services in recent past. What changes were made by, the services after these attacks?
Page 547 :
CHAPTER, , Transport-Level Security, 17.1 Web Security Considerations, Web Security Threats, Web Traffic Security Approaches, 17.2 Transport Layer Security, TLS Architecture, TLS Record Protocol, Change Cipher Spec Protocol, Alert Protocol, Handshake Protocol, Cryptographic Computations, Heartbeat Protocol, SSL/TLS Attacks, TLSv1.3, 17.3 HTTPS, Connection Initiation, Connection Closure, 17.4 Secure Shell (SSH), Transport Layer Protocol, User Authentication Protocol, Connection Protocol, 17.5 Key Terms, Review Questions, and Problems, , 546
Page 548 :
17.1 / WEB SECURITY CONSIDERATIONS, , 547, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Summarize Web security threats and Web traffic security approaches., ◆ Present an overview of Transport Layer Security (TLS)., ◆ Understand the differences between Secure Sockets Layer and Transport, Layer Security., ◆ Compare the pseudorandom function used in Transport Layer Security, with those discussed earlier in the book., ◆ Present an overview of HTTPS (HTTP over SSL)., ◆ Present an overview of Secure Shell (SSH)., , Virtually all businesses, most government agencies, and many individuals now have, Web sites. The number of individuals and companies with Internet access is expanding, rapidly and all of these have graphical Web browsers. As a result, businesses are enthusiastic about setting up facilities on the Web for electronic commerce. But the reality, is that the Internet and the Web are extremely vulnerable to compromises of various, sorts. As businesses wake up to this reality, the demand for secure Web services grows., The topic of Web security is a broad one and can easily fill a book. In this chapter, we begin with a discussion of the general requirements for Web security and then, focus on three standardized schemes that are becoming increasingly important as part, of Web commerce and that focus on security at the transport layer: SSL/TLS, HTTPS,, and SSH., , 17.1 WEB SECURITY CONSIDERATIONS, The World Wide Web is fundamentally a client/server application running over the, Internet and TCP/IP intranets. As such, the security tools and approaches discussed, so far in this book are relevant to the issue of Web security. However, the following, characteristics of Web usage suggest the need for tailored security tools:, ■, , Although Web browsers are very easy to use, Web servers are relatively easy, to configure and manage, and Web content is increasingly easy to develop, the, underlying software is extraordinarily complex. This complex software may, hide many potential security flaws. The short history of the Web is filled with, examples of new and upgraded systems, properly installed, that are vulnerable, to a variety of security attacks., , ■, , A Web server can be exploited as a launching pad into the corporation’s or, agency’s entire computer complex. Once the Web server is subverted, an, attacker may be able to gain access to data and systems not part of the Web, itself but connected to the server at the local site.
Page 549 :
548, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, ■, , Casual and untrained (in security matters) users are common clients for Webbased services. Such users are not necessarily aware of the security risks that, exist and do not have the tools or knowledge to take effective countermeasures., , Web Security Threats, Table 17.1 provides a summary of the types of security threats faced when using the, Web. One way to group these threats is in terms of passive and active attacks. Passive, attacks include eavesdropping on network traffic between browser and server and, gaining access to information on a Web site that is supposed to be restricted. Active, attacks include impersonating another user, altering messages in transit between, client and server, and altering information on a Web site., Another way to classify Web security threats is in terms of the location of the, threat: Web server, Web browser, and network traffic between browser and server., Issues of server and browser security fall into the category of computer system security; Part Six of this book addresses the issue of system security in general but is also, applicable to Web system security. Issues of traffic security fall into the category of, network security and are addressed in this chapter., , Web Traffic Security Approaches, A number of approaches to providing Web security are possible. The various, approaches that have been considered are similar in the services they provide and,, to some extent, in the mechanisms that they use, but they differ with respect to their, scope of applicability and their relative location within the TCP/IP protocol stack., Table 17.1 A Comparison of Threats on the Web, Threats, , Consequences, , Countermeasures, , Integrity, , r Modification of user data, r Trojan horse browser, r Modification of memory, r Modification of message, traffic in transit, , r Loss of information, r Compromise of machine, r Vulnerability to all other, threats, , Cryptographic, checksums, , Confidentiality, , r Eavesdropping on the net, r Theft of info from server, r Theft of data from client, r Info about network, configuration, r Info about which client talks, to server, , r Loss of information, r Loss of privacy, , Encryption, Web, proxies, , Denial of, Service, , r Killing of user threads, r Flooding machine with bogus, requests, r Filling up disk or memory, r Isolating machine by DNS, attacks, , r Disruptive, r Annoying, r Prevent user from getting work, done, , Difficult to prevent, , Authentication, , r Impersonation of legitimate, users, r Data forgery, , r Misrepresentation of user, r Belief that false information, is valid, , Cryptographic, techniques
Page 550 :
17.2 / TRANSPORT LAYER SECURITY, HTTP, HTTP, , FTP, , SMTP, , FTP, , SMTP, , 549, , S/MIME, , SSL or TLS, , Kerberos, , TCP, , TCP, , UDP, , IP/IPSec, , IP, , (a) Network level, , (b) Transport level, , SMTP, , HTTP, TCP, IP, , (c) Application level, , Figure 17.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack, , Figure 17.1 illustrates this difference. One way to provide Web security is, to use IP security (IPsec) (Figure 17.1a). The advantage of using IPsec is that it is, transparent to end users and applications and provides a general-purpose solution., Furthermore, IPsec includes a filtering capability so that only selected traffic need, incur the overhead of IPsec processing., Another relatively general-purpose solution is to implement security just, above TCP (Figure 17.1b). The foremost example of this approach is the Secure, Sockets Layer (SSL) and the follow-on Internet standard known as Transport, Layer Security (TLS). At this level, there are two implementation choices. For full, generality, SSL (or TLS) could be provided as part of the underlying protocol suite, and therefore be transparent to applications. Alternatively, TLS can be embedded, in specific packages. For example, virtually all browsers come equipped with TLS,, and most Web servers have implemented the protocol., Application-specific security services are embedded within the particular, application. Figure 17.1c shows examples of this architecture. The advantage of this, approach is that the service can be tailored to the specific needs of a given application., , 17.2 TRANSPORT LAYER SECURITY, One of the most widely used security services is Transport Layer Security (TSL);, the current version is Version 1.2, defined in RFC 5246. TLS is an Internet standard that evolved from a commercial protocol known as Secure Sockets Layer, (SSL). Although SSL implementations are still around, it has been deprecated by, IETF and is disabled by most corporations offering TLS software. TLS is a generalpurpose service implemented as a set of protocols that rely on TCP. At this level,, there are two implementation choices. For full generality, TLS could be provided, as part of the underlying protocol suite and therefore be transparent to applications. Alternatively, TLS can be embedded in specific packages. For example, most, browsers come equipped with TLS, and most Web servers have implemented the, protocol., , TLS Architecture, TLS is designed to make use of TCP to provide a reliable end-to-end secure service. TLS is not a single protocol but rather two layers of protocols, as illustrated in, Figure 17.2.
Page 551 :
550, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , Handshake, protocol, , Change, cipher spec, protocol, , Alert, protocol, , HTTP, , Heartbeat, protocol, , Record protocol, , TCP, , IP, , Figure 17.2 TLS Protocol Stack, , The TLS Record Protocol provides basic security services to various higherlayer protocols. In particular, the Hypertext Transfer Protocol (HTTP), which, provides the transfer service for Web client/server interaction, can operate on top, of TLS. Three higher-layer protocols are defined as part of TLS: the Handshake, Protocol; the Change Cipher Spec Protocol; and the Alert Protocol. These TLSspecific protocols are used in the management of TLS exchanges and are examined, later in this section. A fourth protocol, the Heartbeat Protocol, is defined in a separate RFC and is also discussed subsequently in this section., Two important TLS concepts are the TLS session and the TLS connection,, which are defined in the specification as follows:, ■, , ■, , Connection: A connection is a transport (in the OSI layering model definition), that provides a suitable type of service. For TLS, such connections are peer-topeer relationships. The connections are transient. Every connection is associated with one session., Session: A TLS session is an association between a client and a server. Sessions, are created by the Handshake Protocol. Sessions define a set of cryptographic, security parameters, which can be shared among multiple connections. Sessions, are used to avoid the expensive negotiation of new security parameters for, each connection., , Between any pair of parties (applications such as HTTP on client and server),, there may be multiple secure connections. In theory, there may also be multiple, simultaneous sessions between parties, but this feature is not used in practice., There are a number of states associated with each session. Once a session is, established, there is a current operating state for both read and write (i.e., receive, and send). In addition, during the Handshake Protocol, pending read and write, states are created. Upon successful conclusion of the Handshake Protocol, the, pending states become the current states., A session state is defined by the following parameters:, ■, ■, , Session identifier: An arbitrary byte sequence chosen by the server to identify, an active or resumable session state., Peer certificate: An X509.v3 certificate of the peer. This element of the state, may be null., , Hiva-Network.Com
Page 552 :
17.2 / TRANSPORT LAYER SECURITY, ■, ■, , ■, ■, , 551, , Compression method: The algorithm used to compress data prior to encryption., Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES,, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation., It also defines cryptographic attributes such as the hash_size., Master secret: 48-byte secret shared between the client and server., Is resumable: A flag indicating whether the session can be used to initiate new, connections., A connection state is defined by the following parameters:, , ■, ■, ■, ■, ■, ■, , ■, , Server and client random: Byte sequences that are chosen by the server and, client for each connection., Server write MAC secret: The secret key used in MAC operations on data sent, by the server., Client write MAC secret: The symmetric key used in MAC operations on data, sent by the client., Server write key: The symmetric encryption key for data encrypted by the, server and decrypted by the client., Client write key: The symmetric encryption key for data encrypted by the, client and decrypted by the server., Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key. This field is first initialized by, the TLS Handshake Protocol. Thereafter, the final ciphertext block from each, record is preserved for use as the IV with the following record., Sequence numbers: Each party maintains separate sequence numbers for, transmitted and received messages for each connection. When a party sends or, receives a “change cipher spec message,” the appropriate sequence number is, set to zero. Sequence numbers may not exceed 264 - 1., , TLS Record Protocol, The TLS Record Protocol provides two services for TLS connections:, ■, ■, , Confidentiality: The Handshake Protocol defines a shared secret key that is, used for conventional encryption of TLS payloads., Message Integrity: The Handshake Protocol also defines a shared secret key, that is used to form a message authentication code (MAC)., , Figure 17.3 indicates the overall operation of the TLS Record Protocol. The, Record Protocol takes an application message to be transmitted, fragments the data, into manageable blocks, optionally compresses the data, applies a MAC, encrypts,, adds a header, and transmits the resulting unit in a TCP segment. Received data, are decrypted, verified, decompressed, and reassembled before being delivered to, higher-level users., The first step is fragmentation. Each upper-layer message is fragmented into, blocks of 214 bytes (16,384 bytes) or less. Next, compression is optionally applied., Compression must be lossless and may not increase the content length by more than
Page 553 :
552, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, Application data, , Fragment, , Compress, , Add MAC, , Encrypt, , Append TLS, record header, , Figure 17.3 TLS Record Protocol Operation, , 1024 bytes.1 In TLSv2, no compression algorithm is specified, so the default compression algorithm is null., The next step in processing is to compute a message authentication code over, the compressed data. TLS makes use of the HMAC algorithm defined in RFC 2104., Recall from Chapter 12 that HMAC is defined as, HMAC K(M) = H[(K + ⊕ opad) ‘ H[(K + ⊕ ipad) ‘ M]], where, = embedded hash function (for TLS, either MD5 or SHA-1), = message input to HMAC, = secret key padded with zeros on the left so that the result is equal to, the block length of the hash code (for MD5 and SHA-1, block, length = 512 bits), ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits), opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits), , H, M, K+, , For TLS, the MAC calculation encompasses the fields indicated in the, following expression:, HMAC_hash(MAC_write_secret, seq_num ‘ TLSCompressed.type ‘, TLSCompressed.version ‘ TLSCompressed.length ‘ TLSCompressed.fragment), The MAC calculation covers all of the fields XXX, plus the field, TLSCompressed.version, which is the version of the protocol being employed., Next, the compressed message plus the MAC are encrypted using symmetric, encryption. Encryption may not increase the content length by more than 1024 bytes,, 1, , Of course, one hopes that compression shrinks rather than expands the data. However, for very short, blocks, it is possible, because of formatting conventions, that the compression algorithm will actually provide output that is longer than the input.
Page 554 :
17.2 / TRANSPORT LAYER SECURITY, , 553, , so that the total length may not exceed 214 + 2048. The following encryption algorithms are permitted:, Block Cipher, , Stream Cipher, , Algorithm, , Key Size, , Algorithm, , Key Size, , AES, 3DES, , 128, 256, 168, , RC4-128, , 128, , For stream encryption, the compressed message plus the MAC are encrypted., Note that the MAC is computed before encryption takes place and that the MAC is, then encrypted along with the plaintext or compressed plaintext., For block encryption, padding may be added after the MAC prior to encryption. The padding is in the form of a number of padding bytes followed by a onebyte indication of the length of the padding. The padding can be any amount that, results in a total that is a multiple of the cipher’s block length, up to a maximum, of 255 bytes. For example, if the cipher block length is 16 bytes (e.g., AES) and if, the plaintext (or compressed text if compression is used) plus MAC plus padding, length byte is 79 bytes long, then the padding length (in bytes) can be 1, 17, 33, and, so on, up to 161. At a padding length of 161, the total length is 79 + 161 = 240. A, variable padding length may be used to frustrate attacks based on an analysis of, the lengths of exchanged messages., The final step of TLS Record Protocol processing is to prepend a header consisting of the following fields:, ■, ■, ■, ■, , Content Type (8 bits): The higher-layer protocol used to process the enclosed, fragment., Major Version (8 bits): Indicates major version of TLS in use. For TLSv2, the, value is 3., Minor Version (8 bits): Indicates minor version in use. For TLSv2, the value is 1., Compressed Length (16 bits): The length in bytes of the plaintext fragment, (or compressed fragment if compression is used). The maximum value is, 214 + 2048., , The content types that have been defined are change_cipher_spec,, alert, handshake, and application_data. The first three are the TLSspecific protocols, discussed next. Note that no distinction is made among the various applications (e.g., HTTP) that might use TLS; the content of the data created by, such applications is opaque to TLS., Figure 17.4 illustrates the TLS record format., , Change Cipher Spec Protocol, The Change Cipher Spec Protocol is one of the four TLS-specific protocols that use, the TLS Record Protocol, and it is the simplest. This protocol consists of a single, message (Figure 17.5a), which consists of a single byte with the value 1. The sole, purpose of this message is to cause the pending state to be copied into the current, state, which updates the cipher suite to be used on this connection.
Page 555 :
554, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, Content Major Minor, type, version version, , Compressed, length, , Encrypted, , Plaintext, (optionally, compressed), , MAC (0, 16, or 20 bytes), , Figure 17.4 TLS Record Format, , Alert Protocol, The Alert Protocol is used to convey TLS-related alerts to the peer entity. As with, other applications that use TLS, alert messages are compressed and encrypted, as, specified by the current state., Each message in this protocol consists of two bytes (Figure 17.5b). The first, byte takes the value warning (1) or fatal (2) to convey the severity of the message., If the level is fatal, TLS immediately terminates the connection. Other connections, on the same session may continue, but no new connections on this session may, be established. The second byte contains a code that indicates the specific alert., The following alerts are always fatal:, ■, ■, ■, , ■, ■, , unexpected_message: An inappropriate message was received., bad_record_mac: An incorrect MAC was received., decompression_failure: The decompression function received improper input, (e.g., unable to decompress or decompress to greater than maximum allowable, length)., handshake_failure: Sender was unable to negotiate an acceptable set of security parameters given the options available., illegal_parameter: A field in a handshake message was out of range or inconsistent with other fields., , 1 byte, , 1 byte, , 3 bytes, , Ú 0 bytes, , 1, , Type, , Length, , Content, , (a) Change Cipher Spec Protocol, , (c) Handshake Protocol, , 1 byte 1 byte, , Ú 1 byte, , Level Alert, , Opaque content, , (b) Alert Protocol, , (d) Other Upper-Layer Protocol (e.g., HTTP), , Figure 17.5 TLS Record Protocol Payload
Page 556 :
17.2 / TRANSPORT LAYER SECURITY, ■, , ■, , ■, , ■, ■, ■, ■, ■, , ■, , 555, , decryption_failed: A ciphertext decrypted in an invalid way; either it was not, an even multiple of the block length or its padding values, when checked, were, incorrect., record_overflow: A TLS record was received with a payload (ciphertext), whose length exceeds 214 + 2048 bytes, or the ciphertext decrypted to a length, of greater than 214 + 1024 bytes., unknown_ca: A valid certificate chain or partial chain was received, but the, certificate was not accepted because the CA certificate could not be located or, could not be matched with a known, trusted CA., access_denied: A valid certificate was received, but when access control was, applied, the sender decided not to proceed with the negotiation., decode_error: A message could not be decoded, because either a field was out, of its specified range or the length of the message was incorrect., export_restriction: A negotiation not in compliance with export restrictions on, key length was detected., protocol_version: The protocol version the client attempted to negotiate is, recognized but not supported., insufficient_security: Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure, than those supported by the client., internal_error: An internal error unrelated to the peer or the correctness of, the protocol makes it impossible to continue., The remaining alerts are the following., , ■, , ■, ■, ■, ■, ■, ■, , ■, ■, , close_notify: Notifies the recipient that the sender will not send any more messages on this connection. Each party is required to send a close_notify alert, before closing the write side of a connection., bad_certificate: A received certificate was corrupt (e.g., contained a signature, that did not verify)., unsupported_certificate: The type of the received certificate is not supported., certificate_revoked: A certificate has been revoked by its signer., certificate_expired: A certificate has expired., certificate_unknown: Some other unspecified issue arose in processing the, certificate, rendering it unacceptable., decrypt_error: A handshake cryptographic operation failed, including being, unable to verify a signature, decrypt a key exchange, or validate a finished, message., user_canceled: This handshake is being canceled for some reason unrelated to, a protocol failure., no_renegotiation: Sent by a client in response to a hello request or by the, server in response to a client hello after initial handshaking. Either of these, messages would normally result in renegotiation, but this alert indicates that, the sender is not able to renegotiate. This message is always a warning.
Page 557 :
556, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , Handshake Protocol, The most complex part of TLS is the Handshake Protocol. This protocol allows, the server and client to authenticate each other and to negotiate an encryption and, MAC algorithm and cryptographic keys to be used to protect data sent in a TLS, record. The Handshake Protocol is used before any application data is transmitted., The Handshake Protocol consists of a series of messages exchanged by client, and server. All of these have the format shown in Figure 17.5c . Each message has, three fields:, ■, ■, ■, , Type (1 byte): Indicates one of 10 messages. Table 17.2 lists the defined message types., Length (3 bytes): The length of the message in bytes., Content ( # 0 bytes): The parameters associated with this message; these are, listed in Table 17.2., , Figure 17.6 shows the initial exchange needed to establish a logical connection, between client and server. The exchange can be viewed as having four phases., PHASE 1. ESTABLISH SECURITY CAPABILITIES Phase 1 initiates a logical connection, and establishes the security capabilities that will be associated with it. The exchange, is initiated by the client, which sends a client_hello message with the following, parameters:, ■, ■, , ■, , Version: The highest TLS version understood by the client., Random: A client-generated random structure consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator. These, values serve as nonces and are used during key exchange to prevent replay, attacks., Session ID: A variable-length session identifier. A nonzero value indicates that, the client wishes to update the parameters of an existing connection or to create a new connection on this session. A zero value indicates that the client, wishes to establish a new connection on a new session., , Table 17.2 TLS Handshake Protocol Message Types, Message Type, , Parameters, , hello_request, , null, , client_hello, , version, random, session id, cipher suite, compression method, , server_hello, , version, random, session id, cipher suite, compression method, , certificate, , chain of X.509v3 certificates, , server_key_exchange, , parameters, signature, , certificate_request, , type, authorities, , server_done, , null, , certificate_verify, , signature, , client_key_exchange, , parameters, signature, , finished, , hash value
Page 558 :
17.2 / TRANSPORT LAYER SECURITY, , Client, , 557, , Server, client_h, , ello, , Phase 1, Establish security capabilities, including, protocol version, session ID, cipher suite,, compression method, and initial random, numbers., , ello, server_h, , te, certifica, ange, ey_exch, server_k, , est, , te_requ, certifica, , Phase 2, Server may send certificate, key exchange,, and request certificate. Server signals end, of hello message phase., , one, , hello_d, , Time, , server_, , certifica, te, client_k, ey_exch, , ange, , certifica, te_verif, , Phase 3, Client sends certificate if requested. Client, sends key exchange. Client may send, certificate verification., , y, , change_, , cipher_, , spec, , finished, , spec, , cipher_, , change_, , Phase 4, Change cipher suite and finish, handshake protocol., , finished, , Note: Shaded transfers are, optional or situation-dependent, messages that are not always sent., , Figure 17.6, ■, , ■, , Handshake Protocol Action, , CipherSuite: This is a list that contains the combinations of cryptographic, algorithms supported by the client, in decreasing order of preference. Each, element of the list (each cipher suite) defines both a key exchange algorithm, and a CipherSpec; these are discussed subsequently., Compression Method: This is a list of the compression methods the client, supports., , After sending the client_hello message, the client waits for the server_, hello message, which contains the same parameters as the client_hello
Page 559 :
558, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , message. For the server_hello message, the following conventions apply. The, Version field contains the lowest of the version suggested by the client and the highest, supported by the server. The Random field is generated by the server and is independent of the client’s Random field. If the SessionID field of the client was nonzero, the, same value is used by the server; otherwise the server’s SessionID field contains the, value for a new session. The CipherSuite field contains the single cipher suite selected, by the server from those proposed by the client. The Compression field contains the, compression method selected by the server from those proposed by the client., The first element of the Ciphersuite parameter is the key exchange method, (i.e., the means by which the cryptographic keys for conventional encryption and, MAC are exchanged). The following key exchange methods are supported., ■, ■, , ■, , ■, , RSA: The secret key is encrypted with the receiver’s RSA public key. A publickey certificate for the receiver’s key must be made available., Fixed Diffie–Hellman: This is a Diffie–Hellman key exchange in which the, server’s certificate contains the Diffie–Hellman public parameters signed by, the certificate authority (CA). That is, the public-key certificate contains the, Diffie–Hellman public-key parameters. The client provides its Diffie–Hellman, public-key parameters either in a certificate, if client authentication is required, or in a key exchange message. This method results in a fixed secret key, between two peers based on the Diffie–Hellman calculation using the fixed, public keys., Ephemeral Diffie-Hellman: This technique is used to create ephemeral (temporary, one-time) secret keys. In this case, the Diffie–Hellman public keys are, exchanged and signed using the sender’s private RSA or DSS key. The receiver, can use the corresponding public key to verify the signature. Certificates are used, to authenticate the public keys. This would appear to be the most secure of the, three Diffie–Hellman options because it results in a temporary, authenticated key., Anonymous Diffie–Hellman: The base Diffie–Hellman algorithm is used, with no authentication. That is, each side sends its public Diffie–Hellman parameters to the other with no authentication. This approach is vulnerable to, man-in-the-middle attacks, in which the attacker conducts anonymous Diffie–, Hellman with both parties., , Following the definition of a key exchange method is the CipherSpec, which, includes the following fields:, ■, , CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES,, 3DES, DES40, or IDEA, , ■, , MACAlgorithm: MD5 or SHA-1, CipherType: Stream or Block, IsExportable: True or False, HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes, Key Material: A sequence of bytes that contain data used in generating the, write keys, IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC), encryption, , ■, ■, ■, ■, ■
Page 560 :
17.2 / TRANSPORT LAYER SECURITY, , 559, , PHASE 2. SERVER AUTHENTICATION AND KEY EXCHANGE The server begins this, phase by sending its certificate if it needs to be authenticated; the message contains one or a chain of X.509 certificates. The certificate message is required for, any agreed-on key exchange method except anonymous Diffie–Hellman. Note, that if fixed Diffie–Hellman is used, this certificate message functions as the server’s key exchange message because it contains the server’s public Diffie–Hellman, parameters., Next, a server_key_exchange message may be sent if it is required. It is not, required in two instances: (1) The server has sent a certificate with fixed Diffie–, Hellman parameters; or (2) RSA key exchange is to be used. The server_key_, exchange message is needed for the following:, ■, , ■, , ■, , Anonymous Diffie–Hellman: The message content consists of the two global, Diffie–Hellman values (a prime number and a primitive root of that number), plus the server’s public Diffie–Hellman key (see Figure 10.1)., Ephemeral Diffie–Hellman: The message content includes the three Diffie–, Hellman parameters provided for anonymous Diffie–Hellman plus a signature, of those parameters., RSA key exchange (in which the server is using RSA but has a signature-only, RSA key): Accordingly, the client cannot simply send a secret key encrypted, with the server’s public key. Instead, the server must create a temporary RSA, public/private key pair and use the server_key_exchange message to send the, public key. The message content includes the two parameters of the temporary, RSA public key (exponent and modulus; see Figure 9.5) plus a signature of, those parameters., , Some further details about the signatures are warranted. As usual, a signature, is created by taking the hash of a message and encrypting it with the sender’s private, key. In this case, the hash is defined as, hash(ClientHello.random ‘ ServerHello.random ‘ ServerParams), So the hash covers not only the Diffie–Hellman or RSA parameters but also the, two nonces from the initial hello messages. This ensures against replay attacks and, misrepresentation. In the case of a DSS signature, the hash is performed using the, SHA-1 algorithm. In the case of an RSA signature, both an MD5 and an SHA-1, hash are calculated, and the concatenation of the two hashes (36 bytes) is encrypted, with the server’s private key., Next, a nonanonymous server (server not using anonymous Diffie–Hellman), can request a certificate from the client. The certificate_request message includes, two parameters: certificate_type and certificate_authorities. The certificate type indicates the public-key algorithm and its use:, ■, ■, ■, ■, , RSA, signature only, DSS, signature only, RSA for fixed Diffie–Hellman; in this case the signature is used only for, authentication, by sending a certificate signed with RSA, DSS for fixed Diffie–Hellman; again, used only for authentication, , Hiva-Network.Com
Page 561 :
560, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , The second parameter in the certificate_request message is a list of the distinguished names of acceptable certificate authorities., The final message in phase 2, and one that is always required, is the server_, done message, which is sent by the server to indicate the end of the server hello and, associated messages. After sending this message, the server will wait for a client, response. This message has no parameters., PHASE 3. CLIENT AUTHENTICATION AND KEY EXCHANGE Upon receipt of the, server_done message, the client should verify that the server provided a valid, certificate (if required) and check that the server_hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server., If the server has requested a certificate, the client begins this phase by sending a certificate message. If no suitable certificate is available, the client sends a, no_certificate alert instead., Next is the client_key_exchange message, which must be sent in this phase., The content of the message depends on the type of key exchange, as follows:, ■, , ■, ■, , RSA: The client generates a 48-byte pre-master secret and encrypts with the, public key from the server’s certificate or temporary RSA key from a server_, key_exchange message. Its use to compute a master secret is explained later., Ephemeral or Anonymous Diffie–Hellman: The client’s public Diffie–Hellman, parameters are sent., Fixed Diffie–Hellman: The client’s public Diffie–Hellman parameters were, sent in a certificate message, so the content of this message is null., , Finally, in this phase, the client may send a certificate_verify message to provide explicit verification of a client certificate. This message is only sent following, any client certificate that has signing capability (i.e., all certificates except those, containing fixed Diffie–Hellman parameters). This message signs a hash code based, on the preceding messages, defined as, CertificateVerify.signature.md5_hash, MD5(handshake_messages);, Certificate.signature.sha_hash, SHA(handshake_messages);, where handshake_messages refers to all Handshake Protocol messages sent or, received starting at client_hello but not including this message. If the user’s, private key is DSS, then it is used to encrypt the SHA-1 hash. If the user’s private, key is RSA, it is used to encrypt the concatenation of the MD5 and SHA-1 hashes., In either case, the purpose is to verify the client’s ownership of the private key for, the client certificate. Even if someone is misusing the client’s certificate, he or she, would be unable to send this message., PHASE 4. FINISH Phase 4 completes the setting up of a secure connection. The client, sends a change_cipher_spec message and copies the pending CipherSpec into the, current CipherSpec. Note that this message is not considered part of the Handshake, Protocol but is sent using the Change Cipher Spec Protocol. The client then immediately sends the finished message under the new algorithms, keys, and secrets.
Page 562 :
17.2 / TRANSPORT LAYER SECURITY, , 561, , The finished message verifies that the key exchange and authentication processes, were successful. The content of the finished message is:, PRF(master_secret, finished_label, MD5(handshake_messages) ‘ SHA@1, (handshake_messages)), where finished_label is the string “client finished” for the client and “server, finished” for the server., In response to these two messages, the server sends its own change_cipher_, spec message, transfers the pending to the current CipherSpec, and sends its finished message. At this point, the handshake is complete and the client and server, may begin to exchange application-layer data., , Cryptographic Computations, Two further items are of interest: (1) the creation of a shared master secret by, means of the key exchange; and (2) the generation of cryptographic parameters, from the master secret., MASTER SECRET CREATION The shared master secret is a one-time 48-byte value, (384 bits) generated for this session by means of secure key exchange. The creation, is in two stages. First, a pre_master_secret is exchanged. Second, the master_, secret is calculated by both parties. For pre_master_secret exchange, there, are two possibilities., ■, , ■, , RSA: A 48-byte pre_master_secret is generated by the client, encrypted with, the server’s public RSA key, and sent to the server. The server decrypts the, ciphertext using its private key to recover the pre_master_secret., Diffie–Hellman: Both client and server generate a Diffie–Hellman public key., After these are exchanged, each side performs the Diffie–Hellman calculation, to create the shared pre_master_secret., Both sides now compute the master_secret as, master_secret =, PRF(pre_master_secret, “master secret”, ClientHello.random ‘ ServerHello, .random), , where ClientHello.random and ServerHello.random are the two nonce, values exchanged in the initial hello messages., The algorithm is performed until 48 bytes of pseudorandom output are produced. The calculation of the key block material (MAC secret keys, session encryption keys, and IVs) is defined as, key_block =, PRF(SecurityParameters.master_secret, “key expansion”,, SecurityParameters.server_random ‘ SecurityParameters.client_random), until enough output has been generated.
Page 563 :
562, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , GENERATION OF CRYPTOGRAPHIC PARAMETERS CipherSpecs require a client write, MAC secret, a server write MAC secret, a client write key, a server write key, a, client write IV, and a server write IV, which are generated from the master secret, in that order. These parameters are generated from the master secret by hashing, the master secret into a sequence of secure bytes of sufficient length for all needed, parameters., The generation of the key material from the master secret uses the same format for generation of the master secret from the pre-master secret as, key_block = MD5(master_secret ‘ SHA(=A> ‘ master_secret ‘, ServerHello.random ‘ ClientHello.random)) ‘, MD5(master_secret ‘ SHA(=BB> ‘ master_secret ‘, ServerHello.random ‘ ClientHello.random)) ‘, MD5(master_secret ‘ SHA(=CCC> ‘ master_secret ‘, ServerHello.random ‘ ClientHello.random)) ‘ c, until enough output has been generated. The result of this algorithmic structure is a, pseudorandom function. We can view the master_secret as the pseudorandom, seed value to the function. The client and server random numbers can be viewed as, salt values to complicate cryptanalysis (see Chapter 21 for a discussion of the use of, salt values)., PSEUDORANDOM FUNCTION TLS makes use of a pseudorandom function referred, to as PRF to expand secrets into blocks of data for purposes of key generation or, validation. The objective is to make use of a relatively small, shared secret value but, to generate longer blocks of data in a way that is secure from the kinds of attacks, made on hash functions and MACs. The PRF is based on the data expansion function (Figure 17.7) given as, P_hash(secret, seed) = HMAC_hash(secret, A(1) ‘ seed) ‘, HMAC_hash(secret, A(2) ‘ seed) ‘, HMAC_hash(secret, A(3) ‘ seed) ‘, where A() is defined as, A(0) = seed, A(i) = HMAC_hash(secret, A(i - 1)), The data expansion function makes use of the HMAC algorithm with either MD5, or SHA-1 as the underlying hash function. As can be seen, P_hash can be iterated, as many times as necessary to produce the required quantity of data. For example, if, P_SHA256 was used to generate 80 bytes of data, it would have to be iterated three, times (through A(3)), producing 96 bytes of data of which the last 16 would be discarded. In this case, P_MD5 would have to be iterated four times, producing exactly, 64 bytes of data. Note that each iteration involves two executions of HMAC, each, of which in turn involves two executions of the underlying hash algorithm.
Page 564 :
17.2 / TRANSPORT LAYER SECURITY, , 563, , Seed, , Secret, , HMAC, A(1), Seed, , Secret, , HMAC, , Secret, , HMAC, A(2), Seed, , Secret, , HMAC, , Secret, , HMAC, A(3), Seed, , Secret, , HMAC, , Length = hash size, , Figure 17.7 TLS Function P_hash(secret, seed), , To make PRF as secure as possible, it uses two hash algorithms in a way that, should guarantee its security if either algorithm remains secure. PRF is defined as, PRF(secret, label, seed) = P_6 hash 7 (secret, label ‘ seed), PRF takes as input a secret value, an identifying label, and a seed value and, produces an output of arbitrary length., , Heartbeat Protocol, In the context of computer networks, a heartbeat is a periodic signal generated by, hardware or software to indicate normal operation or to synchronize other parts of, a system. A heartbeat protocol is typically used to monitor the availability of a protocol entity. In the specific case of TLS, a Heartbeat protocol was defined in 2012 in, RFC 6250 (Transport Layer Security (TLS) and Datagram Transport Layer Security, (DTLS) Heartbeat Extension).
Page 565 :
564, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , The Heartbeat protocol runs on top of the TLS Record Protocol and consists of two message types: heartbeat_request and heartbeat_response., The use of the Heartbeat protocol is established during Phase 1 of the Handshake, protocol (Figure 17.6). Each peer indicates whether it supports heartbeats. If heartbeats are supported, the peer indicates whether it is willing to receive heartbeat_, request messages and respond with heartbeat_response messages or only, willing to send heartbeat_request messages., A heartbeat_request message can be sent at any time. Whenever a request message is received, it should be answered promptly with a corresponding, heartbeat_response message. The heartbeat_request message includes, payload length, payload, and padding fields. The payload is a random content, between 16 bytes and 64 Kbytes in length. The corresponding heartbeat_, response message must include an exact copy of the received payload. The padding is also random content. The padding enables the sender to perform a path, MTU (maximum transfer unit) discovery operation, by sending requests with increasing padding until there is no answer anymore, because one of the hosts on, the path cannot handle the message., The heartbeat serves two purposes. First, it assures the sender that the recipient is still alive, even though there may not have been any activity over the underlying TCP connection for a while. Second, the heartbeat generates activity across, the connection during idle periods, which avoids closure by a firewall that does not, tolerate idle connections., The requirement for the exchange of a payload was designed into the Heartbeat, protocol to support its use in a connectionless version of TLS known as Datagram, Transport Layer Security (DTLS). Because a connectionless service is subject, to packet loss, the payload enables the requestor to match response messages to, request messages. For simplicity, the same version of the Heartbeat protocol is used, with both TLS and DTLS. Thus, the payload is required for both TLS and DTLS., , SSL/TLS ATTACKS, Since the first introduction of SSL in 1994, and the subsequent standardization of, TLS, numerous attacks have been devised against these protocols. The appearance, of each attack has necessitated changes in the protocol, the encryption tools used, or, some aspect of the implementation of SSL and TLS to counter these threats., ATTACK CATEGORIES We can group the attacks into four general categories:, ■, , ■, , Attacks on the handshake protocol: As early as 1998, an approach to compromising the handshake protocol based on exploiting the formatting and, implementation of the RSA encryption scheme was presented [BLEI98]. As, countermeasures were implemented the attack was refined and adjusted to not, only thwart the countermeasures but also speed up the attack [e.g., BARD12]., Attacks on the record and application data protocols: A number of vulnerabilities have been discovered in these protocols, leading to patches to counter the, new threats. As a recent example, in 2011, researchers Thai Duong and Juliano, Rizzo demonstrated a proof of concept called BEAST (Browser Exploit Against, SSL/TLS) that turned what had been considered only a theoretical vulnerability
Page 566 :
17.2 / TRANSPORT LAYER SECURITY, , ■, , ■, , 565, , into a practical attack [GOOD11]. BEAST leverages a type of cryptographic, attack called a chosen-plaintext attack. The attacker mounts the attack by, choosing a guess for the plaintext that is associated with a known ciphertext. The, researchers developed a practical algorithm for launching successful attacks., Subsequent patches were able to thwart this attack. The authors of the BEAST, attack are also the creators of the 2012 CRIME (Compression Ratio Info-leak, Made Easy) attack, which can allow an attacker to recover the content of web, cookies when data compression is used along with TLS [GOOD12]. When used, to recover the content of secret authentication cookies, it allows an attacker to, perform session hijacking on an authenticated web session., Attacks on the PKI: Checking the validity of X.509 certificates is an activity, subject to a variety of attacks, both in the context of SSL/TLS and elsewhere., For example, [GEOR12] demonstrated that commonly used libraries for, SSL/TLS suffer from vulnerable certificate validation implementations. The, authors revealed weaknesses in the source code of OpenSSL, GnuTLS, JSSE,, ApacheHttpClient, Weberknecht, cURL, PHP, Python and applications built, upon or with these products., Other attacks: [MEYE13] lists a number of attacks that do not fit into any of, the preceding categories. One example is an attack announced in 2011 by the, German hacker group The Hackers Choice, which is a DoS attack [KUMA11]., The attack creates a heavy processing load on a server by overwhelming the, target with SSL/TLS handshake requests. Boosting system load is done by, establishing new connections or using renegotiation. Assuming that the majority of computation during a handshake is done by the server, the attack creates, more system load on the server than on the source device, leading to a DoS., The server is forced to continuously recompute random numbers and keys., , The history of attacks and countermeasures for SSL/TLS is representative of, that for other Internet-based protocols. A “perfect” protocol and a “perfect” implementation strategy are never achieved. A constant back-and-forth between threats, and countermeasures determines the evolution of Internet-based protocols., , TLSv1.3, In 2014, the IETF TLS working group began work on a version 1.3 of TLS. The, primary aim is to improve the security of TLS. As of this writing, TLSv1.3 is still, in a draft stage, but the final standard is likely to be very close to the current draft., Among the significant changes from version 1.2 are the following:, ■, , TLSv1.3 removes support for a number of options and functions. Removing code that implements functions no longer needed reduces the chances, of potentially dangerous coding errors and reduces the attack surface. The, deleted items include:, –Compression, –Ciphers that do not offer authenticated encryption, –Static RSA and DH key exchange, –32-bit timestamp as part of the Random parameter in the client_hello, message
Page 567 :
566, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , ■, , ■, , –Renegotiation, –Change Cipher Spec Protocol, –RC4, –Use of MD5 and SHA-224 hashes with signatures, TLSv1.3 uses Diffie–Hellman or Elliptic Curve Diffie–Hellman for key, exchange and does not permit RSA. The danger with RSA is that if the private, key is compromised, all handshakes using these cipher suites will be compromised. With DH or ECDH, a new key is negotiated for each handshake., TLSv1.3 allows for a “1 round trip time” handshake by changing the order of, message sent with establishing a secure connection. The client sends a Client, Key Exchange message containing its cryptographic parameters for key establishment before a cipher suite has been negotiated. This enables a server, to calculate keys for encryption and authentication before sending its first, response. Reducing the number of packets sent during this handshake phase, speeds up the process and reduces the attack surface., , These changes should improve the efficiency and security of TLS., , 17.3 HTTPS, HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure communication between a Web browser and a Web server. The HTTPS, capability is built into all modern Web browsers. Its use depends on the Web server, supporting HTTPS communication. For example, some search engines do not support HTTPS., The principal difference seen by a user of a Web browser is that URL (uniform, resource locator) addresses begin with https:// rather than http://. A normal HTTP, connection uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL., When HTTPS is used, the following elements of the communication are, encrypted:, ■, ■, ■, ■, ■, , URL of the requested document, Contents of the document, Contents of browser forms (filled in by browser user), Cookies sent from browser to server and from server to browser, Contents of HTTP header, , HTTPS is documented in RFC 2818, HTTP Over TLS. There is no fundamental change in using HTTP over either SSL or TLS, and both implementations are, referred to as HTTPS., , Connection Initiation, For HTTPS, the agent acting as the HTTP client also acts as the TLS client. The, client initiates a connection to the server on the appropriate port and then sends, the TLS ClientHello to begin the TLS handshake. When the TLS handshake has
Page 568 :
17.4 / SECURE SHELL (SSH), , 567, , finished, the client may then initiate the first HTTP request. All HTTP data is to be, sent as TLS application data. Normal HTTP behavior, including retained connections, should be followed., There are three levels of awareness of a connection in HTTPS. At the HTTP, level, an HTTP client requests a connection to an HTTP server by sending a connection request to the next lowest layer. Typically, the next lowest layer is TCP,, but it also may be TLS/SSL. At the level of TLS, a session is established between a, TLS client and a TLS server. This session can support one or more connections at, any time. As we have seen, a TLS request to establish a connection begins with the, establishment of a TCP connection between the TCP entity on the client side and, the TCP entity on the server side., , Connection Closure, An HTTP client or server can indicate the closing of a connection by including the, following line in an HTTP record: Connection: close. This indicates that the, connection will be closed after this record is delivered., The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve closing the, underlying TCP connection. At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol to send a close_notify alert., TLS implementations must initiate an exchange of closure alerts before closing a, connection. A TLS implementation may, after sending a closure alert, close the, connection without waiting for the peer to send its closure alert, generating an, “incomplete close”. Note that an implementation that does this may choose to, reuse the session. This should only be done when the application knows (typically, through detecting HTTP message boundaries) that it has received all the message, data that it cares about., HTTP clients also must be able to cope with a situation in which the underlying, TCP connection is terminated without a prior close_notify alert and without a, Connection: close indicator. Such a situation could be due to a programming, error on the server or a communication error that causes the TCP connection to drop., However, the unannounced TCP closure could be evidence of some sort of attack. So, the HTTPS client should issue some sort of security warning when this occurs., , 17.4 SECURE SHELL (SSH), Secure Shell (SSH) is a protocol for secure network communications designed to, be relatively simple and inexpensive to implement. The initial version, SSH1 was, focused on providing a secure remote logon facility to replace TELNET and other, remote logon schemes that provided no security. SSH also provides a more general, client/server capability and can be used for such network functions as file transfer and, email. A new version, SSH2, fixes a number of security flaws in the original scheme., SSH2 is documented as a proposed standard in IETF RFCs 4250 through 4256., SSH client and server applications are widely available for most operating, systems. It has become the method of choice for remote login and X tunneling and
Page 569 :
568, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , SSH User, Authentication Protocol, , SSH, Connection Protocol, , Authenticates the client-side Multiplexes the encrypted, tunnel into several logical, user to the server., channels., , SSH Transport Layer Protocol, Provides server authentication, confidentiality, and integrity., It may optionally also provide compression., , TCP, Transmission control protocol provides reliable, connectionoriented end-to-end delivery., , IP, Internet protocol provides datagram delivery across, multiple networks., , Figure 17.8, , SSH Protocol Stack, , is rapidly becoming one of the most pervasive applications for encryption technology outside of embedded systems., SSH is organized as three protocols that typically run on top of TCP, (Figure 17.8):, ■, , ■, ■, , Transport Layer Protocol: Provides server authentication, data confidentiality,, and data integrity with forward secrecy (i.e., if a key is compromised during, one session, the knowledge does not affect the security of earlier sessions). The, transport layer may optionally provide compression., User Authentication Protocol: Authenticates the user to the server., Connection Protocol: Multiplexes multiple logical communications channels, over a single, underlying SSH connection., , Transport Layer Protocol, HOST KEYS Server authentication occurs at the transport layer, based on the server, possessing a public/private key pair. A server may have multiple host keys using, multiple different asymmetric encryption algorithms. Multiple hosts may share, the same host key. In any case, the server host key is used during key exchange to, authenticate the identity of the host. For this to be possible, the client must have a, priori knowledge of the server’s public host key. RFC 4251 dictates two alternative, trust models that can be used:, 1. The client has a local database that associates each host name (as typed by the, user) with the corresponding public host key. This method requires no centrally, administered infrastructure and no third-party coordination. The downside is that, the database of name-to-key associations may become burdensome to maintain., , Hiva-Network.Com
Page 570 :
17.4 / SECURE SHELL (SSH), , 569, , 2. The host name-to-key association is certified by a trusted certification authority (CA). The client only knows the CA root key and can verify the validity of, all host keys certified by accepted CAs. This alternative eases the maintenance, problem, since ideally, only a single CA key needs to be securely stored on the, client. On the other hand, each host key must be appropriately certified by a, central authority before authorization is possible., PACKET EXCHANGE Figure 17.9 illustrates the sequence of events in the SSH, Transport Layer Protocol. First, the client establishes a TCP connection to the, server. This is done via the TCP protocol and is not part of the Transport Layer, Protocol. Once the connection is established, the client and server exchange data,, referred to as packets, in the data field of a TCP segment. Each packet is in the, following format (Figure 17.10)., ■, ■, ■, , Packet length: Length of the packet in bytes, not including the packet length, and MAC fields., Padding length: Length of the random padding field., Payload: Useful contents of the packet. Prior to algorithm negotiation, this, field is uncompressed. If compression is negotiated, then in subsequent, packets, this field is compressed., , Client, , Server, , Establish TCP Connection, SSH-protoversion-softwareversion, Identification string, exchange, , SSH-protoversion-softwareversion, , SSH_MSG_KEXINIT, Algorithm, negotiation, , SSH_MSG_KEXINIT, , Key Exchange, , SSH_MSG_NEWKEYS, End of, key exchange, , Service, request, , Figure 17.9, , SSH_MSG_NEWKEYS, , SSH_MSG_SERVICE_REQUEST, , SSH Transport Layer Protocol Packet Exchanges
Page 571 :
570, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, Payload, , COMPRESS, , se q #, , pktl, , pdl, , Compressed payload, , Pad d in g, , ENCRYPT, , MAC, , Ciphertext, , SSH Packet, pktl = packet length, pdl = padding length, , Figure 17.10, , ■, , ■, , SSH Transport Layer Protocol Packet Formation, , Random padding: Once an encryption algorithm has been negotiated, this, field is added. It contains random bytes of padding so that the total length of, the packet (excluding the MAC field) is a multiple of the cipher block size, or, 8 bytes for a stream cipher., Message authentication code (MAC): If message authentication has been, negotiated, this field contains the MAC value. The MAC value is computed, over the entire packet plus a sequence number, excluding the MAC field. The, sequence number is an implicit 32-bit packet sequence that is initialized to, zero for the first packet and incremented for every packet. The sequence number is not included in the packet sent over the TCP connection., , Once an encryption algorithm has been negotiated, the entire packet, (excluding the MAC field) is encrypted after the MAC value is calculated., The SSH Transport Layer packet exchange consists of a sequence of steps, (Figure 17.9). The first step, the identification string exchange, begins with the client, sending a packet with an identification string of the form:, SSH-protoversion-softwareversion SP comments CR LF
Page 572 :
17.4 / SECURE SHELL (SSH), , 571, , where SP,CR, and LF are space character, carriage return, and line feed, respectively. An example of a valid string is SSH-2.0-billsSSH_3.6.3q3<CR><LF>., The server responds with its own identification string. These strings are used in the, Diffie–Hellman key exchange., Next comes algorithm negotiation. Each side sends an SSH_MSG_KEXINIT, containing lists of supported algorithms in the order of preference to the sender., There is one list for each type of cryptographic algorithm. The algorithms include, key exchange, encryption, MAC algorithm, and compression algorithm. Table 17.3, shows the allowable options for encryption, MAC, and compression. For each category, the algorithm chosen is the first algorithm on the client’s list that is also supported by the server., The next step is key exchange. The specification allows for alternative methods of key exchange, but at present, only two versions of Diffie–Hellman key, exchange are specified. Both versions are defined in RFC 2409 and require only one, packet in each direction. The following steps are involved in the exchange. In this,, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup, of GF(p); q is the order of the subgroup; V_S is S’s identification string; V_C is, , Table 17.3, , SSH Transport Layer Cryptographic Algorithms, Cipher, , MAC algorithm, , 3des-cbc*, , Three-key 3DES in CBC, mode, , hmac-sha1*, , HMAC-SHA1; digest, length = key length = 20, , blowfish-cbc, , Blowfish in CBC mode, , hmac-sha1-96**, , First 96 bits of HMACSHA1; digest length = 12;, key length = 20, , twofish256-cbc, , Twofish in CBC mode with, a 256-bit key, , hmac-md5, , HMAC-MD5; digest, length = key length = 16, , twofish192-cbc, , Twofish with a 192-bit key, , hmac-md5-96, , twofish128-cbc, , Twofish with a 128-bit key, , First 96 bits of, HMAC-MD5;, digest length = 12;, key length = 16, , aes256-cbc, , AES in CBC mode with a, 256-bit key, , aes192-cbc, , AES with a 192-bit key, , none*, , No compression, , aes128-cbc**, , AES with a 128-bit key, , zlib, , Defined in RFC 1950 and, RFC 1951, , Serpent256-cbc, , Serpent in CBC mode with, a 256-bit key, , Serpent192-cbc, , Serpent with a 192-bit key, , Serpent128-cbc, , Serpent with a 128-bit key, , arcfour, , RC4 with a 128-bit key, , cast128-cbc, , CAST-128 in CBC mode, , * = Required, ** = Recommended, , Compression algorithm
Page 573 :
572, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , C’s identification string; K_S is S’s public host key; I_C is C’s SSH_MSG_KEXINIT, message and I_S is S’s SSH_MSG_KEXINIT message that have been exchanged, before this part begins. The values of p, g, and q are known to both client and server, as a result of the algorithm selection negotiation. The hash function hash() is also, decided during algorithm negotiation., 1. C generates a random number x(1 6 x 6 q) and computes e = gx mod p. C, sends e to S., 2. S generates a random number y(0 6 y 6 q) and computes f = gy mod p., S receives e. It computes K = e y mod p, H = hash(V_C ‘ V_S ‘ I_C ‘ I_S ‘ K_S ‘, e ‘ f ‘ K), and signature s on H with its private host key. S sends (K_S ‘ f ‘ s), to C. The signing operation may involve a second hashing operation., 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local, database). C is also allowed to accept the key without verification; however,, doing so will render the protocol insecure against active attacks (but may be, desirable for practical reasons in the short term in many environments). C then, computes K = f x mod p, H = hash(V_C ‘ V_S ‘ I_C ‘ I_S ‘ K_S ‘ e ‘ f ‘ K), and, verifies the signature s on H., As a result of these steps, the two sides now share a master key K. In addition,, the server has been authenticated to the client, because the server has used its private key to sign its half of the Diffie-Hellman exchange. Finally, the hash value H, serves as a session identifier for this connection. Once computed, the session identifier is not changed, even if the key exchange is performed again for this connection, to obtain fresh keys., The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS, packets. At this point, both sides may start using the keys generated from K, as discussed subsequently., The final step is service request. The client sends an SSH_MSG_SERVICE_, REQUEST packet to request either the User Authentication or the Connection, Protocol. Subsequent to this, all data is exchanged as the payload of an SSH, Transport Layer packet, protected by encryption and MAC., KEY GENERATION The keys used for encryption and MAC (and any needed IVs), are generated from the shared secret key K, the hash value from the key exchange, H, and the session identifier, which is equal to H unless there has been a subsequent, key exchange after the initial key exchange. The values are computed as follows., ■, ■, ■, ■, ■, ■, , Initial IV client to server: HASH(K ‘ H ‘ ;A< ‘ session_id), Initial IV server to client: HASH(K ‘ H ‘ ;B< ‘ session_id), Encryption key client to server: HASH(K ‘ H ‘ ;C< ‘ session_id), Encryption key server to client: HASH(K ‘ H ‘ ;D< ‘ session_id), Integrity key client to server: HASH(K ‘ H ‘ ;E< ‘ session_id), Integrity key server to client: HASH(K ‘ H ‘ ;F< ‘ session_id), , where HASH() is the hash function determined during algorithm negotiation.
Page 574 :
17.4 / SECURE SHELL (SSH), , 573, , User Authentication Protocol, The User Authentication Protocol provides the means by which the client is, authenticated to the server., MESSAGE TYPES AND FORMATS Three types of messages are always used in the User, Authentication Protocol. Authentication requests from the client have the format:, byte, , SSH_MSG_USERAUTH_REQUEST (50), , string, , user name, , string, , service name, , string, , method name, , ..., , method specific fields, , where user name is the authorization identity the client is claiming, service, name is the facility to which the client is requesting access (typically the SSH, Connection Protocol), and method name is the authentication method being, used in this request. The first byte has decimal value 50, which is interpreted as, SSH_MSG_USERAUTH_REQUEST., If the server either (1) rejects the authentication request or (2) accepts the, request but requires one or more additional authentication methods, the server, sends a message with the format:, byte, , SSH_MSG_USERAUTH_FAILURE (51), , name-list, , authentications that can continue, , boolean, , partial success, , where the name-list is a list of methods that may productively continue the dialog., If the server accepts authentication, it sends a single byte message: SSH_MSG_, USERAUTH_SUCCESS (52)., MESSAGE EXCHANGE The message exchange involves the following steps., 1. The client sends a SSH_MSG_USERAUTH_REQUEST with a requested method, of none., 2. The server checks to determine if the user name is valid. If not, the server, returns SSH_MSG_USERAUTH_FAILURE with the partial success value of, false. If the user name is valid, the server proceeds to step 3., 3. The server returns SSH_MSG_USERAUTH_FAILURE with a list of one or more, authentication methods to be used., 4. The client selects one of the acceptable authentication methods and sends a, SSH_MSG_USERAUTH_REQUEST with that method name and the required, method-specific fields. At this point, there may be a sequence of exchanges to, perform the method.
Page 575 :
574, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , 5. If the authentication succeeds and more authentication methods are required,, the server proceeds to step 3, using a partial success value of true. If the, authentication fails, the server proceeds to step 3, using a partial success value, of false., 6. When all required authentication methods succeed, the server sends a, SSH_MSG_USERAUTH_SUCCESS message, and the Authentication Protocol, is over., AUTHENTICATION METHODS The server may require one or more of the following, authentication methods., ■, , ■, ■, , publickey: The details of this method depend on the public-key algorithm, chosen. In essence, the client sends a message to the server that contains, the client’s public key, with the message signed by the client’s private key., When the server receives this message, it checks whether the supplied key, is acceptable for authentication and, if so, it checks whether the signature is, correct., password: The client sends a message containing a plaintext password,, which is protected by encryption by the Transport Layer Protocol., hostbased: Authentication is performed on the client’s host rather than the, client itself. Thus, a host that supports multiple clients would provide authentication for all its clients. This method works by having the client send a signature created with the private key of the client host. Thus, rather than directly, verifying the user’s identity, the SSH server verifies the identity of the client, host—and then believes the host when it says the user has already authenticated on the client side., , Connection Protocol, The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol, and assumes that a secure authentication connection is in use.2 That secure authentication connection, referred to as a tunnel, is used by the Connection Protocol to, multiplex a number of logical channels., CHANNEL MECHANISM All types of communication using SSH, such as a terminal, session, are supported using separate channels. Either side may open a channel., For each channel, each side associates a unique channel number, which need not be, the same on both ends. Channels are flow controlled using a window mechanism., No data may be sent to a channel until a message is received to indicate that window, space is available., 2, , RFC 4254, The Secure Shell (SSH) Connection Protocol, states that the Connection Protocol runs on, top of the Transport Layer Protocol and the User Authentication Protocol. RFC 4251, SSH Protocol, Architecture, states that the Connection Protocol runs over the User Authentication Protocol. In fact, the, Connection Protocol runs over the Transport Layer Protocol, but assumes that the User Authentication, Protocol has been previously invoked.
Page 576 :
17.4 / SECURE SHELL (SSH), , 575, , The life of a channel progresses through three stages: opening a channel, data, transfer, and closing a channel., When either side wishes to open a new channel, it allocates a local number for, the channel and then sends a message of the form:, byte, , SSH_MSG_CHANNEL_OPEN, , string, , channel type, , uint32, , sender channel, , uint32, , initial window size, , uint32, , maximum packet size, , ...., , channel type specific data follows, , where uint32 means unsigned 32-bit integer. The channel type identifies the application for this channel, as described subsequently. The sender channel is the local, channel number. The initial window size specifies how many bytes of channel data, can be sent to the sender of this message without adjusting the window. The maximum packet size specifies the maximum size of an individual data packet that can, be sent to the sender. For example, one might want to use smaller packets for interactive connections to get better interactive response on slow links., If the remote side is able to open the channel, it returns a SSH_MSG_CHANNEL_, OPEN_CONFIRMATION message, which includes the sender channel number, the, recipient channel number, and window and packet size values for incoming traffic., Otherwise, the remote side returns a SSH_MSG_CHANNEL_OPEN_FAILURE, message with a reason code indicating the reason for failure., Once a channel is open, data transfer is performed using a SSH_MSG_, CHANNEL_DATA message, which includes the recipient channel number and a block, of data. These messages, in both directions, may continue as long as the channel, is open., When either side wishes to close a channel, it sends a SSH_MSG_CHANNEL_, CLOSE message, which includes the recipient channel number., Figure 17.11 provides an example of Connection Protocol Message Exchange., CHANNEL TYPES Four channel types are recognized in the SSH Connection Protocol, specification., ■, , ■, , session: The remote execution of a program. The program may be a shell, an, application such as file transfer or email, a system command, or some built-in, subsystem. Once a session channel is opened, subsequent requests are used to, start the remote program., x11: This refers to the X Window System, a computer software system and, network protocol that provides a graphical user interface (GUI) for networked computers. X allows applications to run on a network server but to be, displayed on a desktop machine.
Page 577 :
576, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , Client, , Server, , Establish Authenticated Transport Layer Connection, SSH_MSG_CHANNEL_OPEN, , Open a, channel, , SSH_MSG_CHANNEL_OPEN_CONFIRMATION, , SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_DATA, , Data, transfer, SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_DATA, , Close a, channel, Figure 17.11, , ■, ■, , SSH_MSG_CHANNEL_CLOSE, , Example of SSH Connection Protocol Message Exchange, , forwarded-tcpip: This is remote port forwarding, as explained in the next, subsection., direct-tcpip: This is local port forwarding, as explained in the next subsection., , PORT FORWARDING One of the most useful features of SSH is port forwarding. In, essence, port forwarding provides the ability to convert any insecure TCP connection into a secure SSH connection. This is also referred to as SSH tunneling. We, need to know what a port is in this context. A port is an identifier of a user of, TCP. So, any application that runs on top of TCP has a port number. Incoming TCP, traffic is delivered to the appropriate application on the basis of the port number., An application may employ multiple port numbers. For example, for the Simple, Mail Transfer Protocol (SMTP), the server side generally listens on port 25, so an
Page 578 :
17.4 / SECURE SHELL (SSH), , 577, , incoming SMTP request uses TCP and addresses the data to destination port 25., TCP recognizes that this is the SMTP server address and routes the data to the, SMTP server application., Figure 17.12 illustrates the basic concept behind port forwarding. We have, a client application that is identified by port number x and a server application, identified by port number y. At some point, the client application invokes the local, TCP entity and requests a connection to the remote server on port y. The local, TCP entity negotiates a TCP connection with the remote TCP entity, such that the, connection links local port x to remote port y., To secure this connection, SSH is configured so that the SSH Transport Layer, Protocol establishes a TCP connection between the SSH client and server entities,, with TCP port numbers a and b, respectively. A secure SSH tunnel is established, , Client, , Server, , Client, application, , Server, application, , x, TCP, entity, , y, Unsecure TCP connection, , TCP, entity, , (a) Connection via TCP, , Client, application, x, , Server, application, , Secure SSH tunnel, , SSH, entity, , SSH, entity, , a, TCP, entity, , b, Unsecure TCP connection, , (b) Connection via SSH tunnel, Figure 17.12, , Hiva-Network.Com, , y, , SSH Transport Layer Packet Exchanges, , TCP, entity
Page 579 :
578, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , over this TCP connection. Traffic from the client at port x is redirected to the local, SSH entity and travels through the tunnel where the remote SSH entity delivers the, data to the server application on port y. Traffic in the other direction is similarly, redirected., SSH supports two types of port forwarding: local forwarding and remote forwarding. Local forwarding allows the client to set up a “hijacker” process. This will, intercept selected application-level traffic and redirect it from an unsecured TCP, connection to a secure SSH tunnel. SSH is configured to listen on selected ports., SSH grabs all traffic using a selected port and sends it through an SSH tunnel. On, the other end, the SSH server sends the incoming traffic to the destination port dictated by the client application., The following example should help clarify local forwarding. Suppose you have, an email client on your desktop and use it to get email from your mail server via the, Post Office Protocol (POP). The assigned port number for POP3 is port 110. We, can secure this traffic in the following way:, 1. The SSH client sets up a connection to the remote server., 2. Select an unused local port number, say 9999, and configure SSH to accept, traffic from this port destined for port 110 on the server., 3. The SSH client informs the SSH server to create a connection to the destination, in this case mailserver port 110., 4. The client takes any bits sent to local port 9999 and sends them to the server, inside the encrypted SSH session. The SSH server decrypts the incoming bits, and sends the plaintext to port 110., 5. In the other direction, the SSH server takes any bits received on port 110 and, sends them inside the SSH session back to the client, who decrypts and sends, them to the process connected to port 9999., With remote forwarding, the user’s SSH client acts on the server’s behalf., The client receives traffic with a given destination port number, places the traffic on the correct port and sends it to the destination the user chooses. A typical, example of remote forwarding is the following. You wish to access a server at, work from your home computer. Because the work server is behind a firewall, it, will not accept an SSH request from your home computer. However, from work, you can set up an SSH tunnel using remote forwarding. This involves the following steps., 1. From the work computer, set up an SSH connection to your home computer., The firewall will allow this, because it is a protected outgoing connection., 2. Configure the SSH server to listen on a local port, say 22, and to deliver data, across the SSH connection addressed to remote port, say 2222., 3. You can now go to your home computer, and configure SSH to accept traffic, on port 2222., 4. You now have an SSH tunnel that can be used for remote logon to the work, server.
Page 580 :
17.5 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 579, , 17.5 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, Alert protocol, Change Cipher Spec protocol, Handshake protocol, , HTTPS (HTTP over SSL), Master Secret, Secure Shell (SSH), , Secure Socket Layer (SSL), Transport Layer Security, (TLS), , Review Questions, 17.1, 17.2, 17.3, 17.4, 17.5, 17.6, 17.7, 17.8, 17.9, 17.10, , What are the advantages of each of the three approaches shown in Figure 17.1?, What protocols comprise TLS?, What is the difference between a TLS connection and a TLS session?, List and briefly define the parameters that define a TLS session state., List and briefly define the parameters that define a TLS session connection., What services are provided by the TLS Record Protocol?, What steps are involved in the TLS Record Protocol transmission?, Give brief details about different level of awareness of a connection in HTTPS., Which protocol was replaced by SSH and why? Which version is currently in the process of being standardized?, List and briefly define the SSH protocols., , Problems, 17.1, 17.2, 17.3, , In SSL and TLS, why is there a separate Change Cipher Spec Protocol rather than, including a change_cipher_spec message in the Handshake Protocol?, What purpose does the MAC serve during the change cipher spec TLS exchange?, Consider the following threats to Web security and describe how each is countered by, a particular feature of TLS., a. Brute-Force Cryptanalytic Attack: An exhaustive search of the key space for a, conventional encryption algorithm., b. Known Plaintext Dictionary Attack: Many messages will contain predictable, plaintext, such as the HTTP GET command. An attacker constructs a dictionary containing every possible encryption of the known-plaintext message. When, an encrypted message is intercepted, the attacker takes the portion containing, the encrypted known plaintext and looks up the ciphertext in the dictionary. The, ciphertext should match against an entry that was encrypted with the same secret, key. If there are several matches, each of these can be tried against the full ciphertext to determine the right one. This attack is especially effective against small key, sizes (e.g., 40-bit keys)., c. Replay Attack: Earlier TLS handshake messages are replayed., d. Man-in-the-Middle Attack: An attacker interposes during key exchange, acting as, the client to the server and as the server to the client., e. Password Sniffing: Passwords in HTTP or other application traffic are eavesdropped., f. IP Spoofing: Uses forged IP addresses to fool a host into accepting bogus data.
Page 581 :
580, , CHAPTER 17 / TRANSPORT-LEVEL SECURITY, , 17.4, , 17.5, , g. IP Hijacking: An active, authenticated connection between two hosts is disrupted, and the attacker takes the place of one of the hosts., h. SYN Flooding: An attacker sends TCP SYN messages to request a connection, but does not respond to the final message to establish the connection fully. The, attacked TCP module typically leaves the “half-open connection” around for a few, minutes. Repeated SYN messages can clog the TCP module., Based on what you have learned in this chapter, is it possible in TLS for the receiver, to reorder TLS record blocks that arrive out of order? If so, explain how it can be, done. If not, why not?, For SSH packets, what is the advantage, if any, of not including the MAC in the scope, of the packet encryption?
Page 582 :
CHAPTER, , Wireless Network Security, 18.1 Wireless Security, Wireless Network Threats, Wireless Security Measures, 18.2 Mobile Device Security, Security Threats, Mobile Device Security Strategy, 18.3 IEEE 802.11 Wireless LAN Overview, The Wi-Fi Alliance, IEEE 802 Protocol Architecture, IEEE 802.11 Network Components and Architectural Model, IEEE 802.11 Services, 18.4 IEEE 802.11i Wireless LAN Security, IEEE 802.11i Services, IEEE 802.11i Phases of Operation, Discovery Phase, Authentication Phase, Key Management Phase, Protected Data Transfer Phase, The IEEE 802.11i Pseudorandom Function, 18.5 Key Terms, Review Questions, and Problems, , 581
Page 583 :
582, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆ Present an overview of security threats and countermeasures for wireless, networks., ◆ Understand the unique security threats posed by the use of mobile devices, with enterprise networks., ◆ Describe the principal elements in a mobile device security strategy., ◆ Understand the essential elements of the IEEE 802.11 wireless LAN, standard., ◆ Summarize the various components of the IEEE 802.11i wireless LAN, security architecture., , This chapter begins with a general overview of wireless security issues. We then focus, on the relatively new area of mobile device security, examining threats and countermeasures for mobile devices used in the enterprise. Then, we look at the IEEE 802.11i, standard for wireless LAN security. This standard is part of IEEE 802.11, also referred, to as Wi-Fi. We begin the discussion with an overview of IEEE 802.11, and then we, look in some detail at IEEE 802.11i., , 18.1 WIRELESS SECURITY, Wireless networks, and the wireless devices that use them, introduce a host of security problems over and above those found in wired networks. Some of the key factors contributing to the higher security risk of wireless networks compared to wired, networks include the following [MA10]:, ■, , Channel: Wireless networking typically involves broadcast communications,, which is far more susceptible to eavesdropping and jamming than wired, networks. Wireless networks are also more vulnerable to active attacks that, exploit vulnerabilities in communications protocols., , ■, , Mobility: Wireless devices are, in principal and usually in practice, far more, portable and mobile than wired devices. This mobility results in a number of, risks, described subsequently., Resources: Some wireless devices, such as smartphones and tablets, have, sophisticated operating systems but limited memory and processing resources, with which to counter threats, including denial of service and malware., Accessibility: Some wireless devices, such as sensors and robots, may be left, unattended in remote and/or hostile locations. This greatly increases their, vulnerability to physical attacks., , ■, , ■
Page 584 :
18.1 / WIRELESS SECURITY, , Endpoint, , Wireless medium, , 583, , Access point, , Figure 18.1 Wireless Networking Components, , In simple terms, the wireless environment consists of three components that, provide point of attack (Figure 18.1). The wireless client can be a cell phone, a, Wi-Fi–enabled laptop or tablet, a wireless sensor, a Bluetooth device, and so on., The wireless access point provides a connection to the network or service. Examples, of access points are cell towers, Wi-Fi hotspots, and wireless access points to wired, local or wide area networks. The transmission medium, which carries the radio, waves for data transfer, is also a source of vulnerability., , Wireless Network Threats, [CHOI08] lists the following security threats to wireless networks:, ■, , ■, , ■, , ■, , ■, , ■, , Accidental association: Company wireless LANs or wireless access points to, wired LANs in close proximity (e.g., in the same or neighboring buildings), may create overlapping transmission ranges. A user intending to connect to, one LAN may unintentionally lock on to a wireless access point from a neighboring network. Although the security breach is accidental, it nevertheless, exposes resources of one LAN to the accidental user., Malicious association: In this situation, a wireless device is configured to, appear to be a legitimate access point, enabling the operator to steal passwords from legitimate users and then penetrate a wired network through a, legitimate wireless access point., Ad hoc networks: These are peer-to-peer networks between wireless computers with no access point between them. Such networks can pose a security, threat due to a lack of a central point of control., Nontraditional networks: Nontraditional networks and links, such as personal, network Bluetooth devices, barcode readers, and handheld PDAs, pose a security risk in terms of both eavesdropping and spoofing., Identity theft (MAC spoofing): This occurs when an attacker is able to eavesdrop on network traffic and identify the MAC address of a computer with, network privileges., Man-in-the middle attacks: This type of attack is described in Chapter 10 in, the context of the Diffie–Hellman key exchange protocol. In a broader sense,, this attack involves persuading a user and an access point to believe that they, are talking to each other when in fact the communication is going through an, intermediate attacking device. Wireless networks are particularly vulnerable, to such attacks.
Page 585 :
584, , CHAPTER 18 / WIRELESS NETWORK SECURITY, ■, , ■, , Denial of service (DoS): This type of attack is discussed in detail in Chapter, 21. In the context of a wireless network, a DoS attack occurs when an attacker, continually bombards a wireless access point or some other accessible wireless, port with various protocol messages designed to consume system resources., The wireless environment lends itself to this type of attack, because it is so, easy for the attacker to direct multiple wireless messages at the target., Network injection: A network injection attack targets wireless access points, that are exposed to nonfiltered network traffic, such as routing protocol messages or network management messages. An example of such an attack is, one in which bogus reconfiguration commands are used to affect routers and, switches to degrade network performance., , Wireless Security Measures, Following [CHOI08], we can group wireless security measures into those dealing, with wireless transmissions, wireless access points, and wireless networks (consisting of wireless routers and endpoints)., SECURING WIRELESS TRANSMISSIONS The principal threats to wireless transmission, are eavesdropping, altering or inserting messages, and disruption. To deal with, eavesdropping, two types of countermeasures are appropriate:, ■, , ■, , Signal-hiding techniques: Organizations can take a number of measures to, make it more difficult for an attacker to locate their wireless access points,, including turning off service set identifier (SSID) broadcasting by wireless, access points; assigning cryptic names to SSIDs; reducing signal strength to the, lowest level that still provides requisite coverage; and locating wireless access, points in the interior of the building, away from windows and exterior walls., Greater security can be achieved by the use of directional antennas and of, signal-shielding techniques., Encryption: Encryption of all wireless transmission is effective against eavesdropping to the extent that the encryption keys are secured., , The use of encryption and authentication protocols is the standard method of, countering attempts to alter or insert transmissions., The methods discussed in Chapter 21 for dealing with DoS apply to wireless, transmissions. Organizations can also reduce the risk of unintentional DoS attacks., Site surveys can detect the existence of other devices using the same frequency, range, to help determine where to locate wireless access points. Signal strengths can, be adjusted and shielding used in an attempt to isolate a wireless environment from, competing nearby transmissions., SECURING WIRELESS ACCESS POINTS The main threat involving wireless access, points is unauthorized access to the network. The principal approach for preventing, such access is the IEEE 802.1X standard for port-based network access control. The, standard provides an authentication mechanism for devices wishing to attach to a, LAN or wireless network. The use of 802.1X can prevent rogue access points and, other unauthorized devices from becoming insecure backdoors., Section 16.3 provides an introduction to 802.1X.
Page 586 :
18.2 / MOBILE DEVICE SECURITY, , 585, , SECURING WIRELESS NETWORKS [CHOI08] recommends the following techniques, for wireless network security:, 1. Use encryption. Wireless routers are typically equipped with built-in encryption mechanisms for router-to-router traffic., 2. Use antivirus and antispyware software, and a firewall. These facilities should, be enabled on all wireless network endpoints., 3. Turn off identifier broadcasting. Wireless routers are typically configured to, broadcast an identifying signal so that any device within range can learn of, the router’s existence. If a network is configured so that authorized devices, know the identity of routers, this capability can be disabled, so as to thwart, attackers., 4. Change the identifier on your router from the default. Again, this measure, thwarts attackers who will attempt to gain access to a wireless network using, default router identifiers., 5. Change your router’s pre-set password for administration. This is another, prudent step., 6. Allow only specific computers to access your wireless network. A router can, be configured to only communicate with approved MAC addresses. Of course,, MAC addresses can be spoofed, so this is just one element of a security strategy., , 18.2 MOBILE DEVICE SECURITY, Prior to the widespread use of smartphones, the dominant paradigm for computer, and network security in organizations was as follows. Corporate IT was tightly controlled. User devices were typically limited to Windows PCs. Business applications, were controlled by IT and either run locally on endpoints or on physical servers, in data centers. Network security was based upon clearly defined perimeters that, separated trusted internal networks from the untrusted Internet. Today, there have, been massive changes in each of these assumptions. An organization’s networks, must accommodate the following:, ■, , ■, , Growing use of new devices: Organizations are experiencing significant growth, in employee use of mobile devices. In many cases, employees are allowed to, use a combination of endpoint devices as part of their day-to-day activities., Cloud-based applications: Applications no longer run solely on physical, servers in corporate data centers. Quite the opposite, applications can run, anywhere—on traditional physical servers, on mobile virtual servers, or in the, cloud. Additionally, end users can now take advantage of a wide variety of, cloud-based applications and IT services for personal and professional use., Facebook can be used for an employee’s personal profiles or as a component, of a corporate marketing campaign. Employees depend upon Skype to speak, with friends abroad or for legitimate business video conferencing. Dropbox, and Box can be used to distribute documents between corporate and personal, devices for mobility and user productivity.
Page 587 :
586, , CHAPTER 18 / WIRELESS NETWORK SECURITY, ■, , ■, , De-perimeterization: Given new device proliferation, application mobility,, and cloud-based consumer and corporate services, the notion of a static network perimeter is all but gone. Now there are a multitude of network perimeters around devices, applications, users, and data. These perimeters have also, become quite dynamic as they must adapt to various environmental conditions, such as user role, device type, server virtualization mobility, network location,, and time-of-day., External business requirements: The enterprise must also provide guests,, third-party contractors, and business partners network access using various, devices from a multitude of locations., , The central element in all of these changes is the mobile computing device., Mobile devices have become an essential element for organizations as part of the, overall network infrastructure. Mobile devices such as smartphones, tablets, and, memory sticks provide increased convenience for individuals as well as the potential for increased productivity in the workplace. Because of their widespread use, and unique characteristics, security for mobile devices is a pressing and complex, issue. In essence, an organization needs to implement a security policy through a, combination of security features built into the mobile devices and additional security controls provided by network components that regulate the use of the mobile, devices., , Security Threats, Mobile devices need additional, specialized protection measures beyond those, implemented for other client devices, such as desktop and laptop devices that are, used only within the organization’s facilities and on the organization’s networks., SP 800-14 (Guidelines for Managing and Securing Mobile Devices in the Enterprise,, July 2012) lists seven major security concerns for mobile devices. We examine each, of these in turn., LACK OF PHYSICAL SECURITY CONTROLS Mobile devices are typically under the complete control of the user, and are used and kept in a variety of locations outside the, organization’s control, including off premises. Even if a device is required to remain, on premises, the user may move the device within the organization between secure, and nonsecured locations. Thus, theft and tampering are realistic threats., The security policy for mobile devices must be based on the assumption that, any mobile device may be stolen or at least accessed by a malicious party. The threat, is twofold: A malicious party may attempt to recover sensitive data from the device, itself, or may use the device to gain access to the organization’s resources., USE OF UNTRUSTED MOBILE DEVICES In addition to company-issued and companycontrolled mobile devices, virtually all employees will have personal smartphones, and/or tablets. The organization must assume that these devices are not trustworthy., That is, the devices may not employ encryption and either the user or a third party, may have installed a bypass to the built-in restrictions on security, operating system, use, and so on., , Hiva-Network.Com
Page 588 :
18.2 / MOBILE DEVICE SECURITY, , 587, , USE OF UNTRUSTED NETWORKS If a mobile device is used on premises, it can connect, to organization resources over the organization’s own in-house wireless networks., However, for off-premises use, the user will typically access organizational resources, via Wi-Fi or cellular access to the Internet and from the Internet to the organization. Thus, traffic that includes an off-premises segment is potentially susceptible to, eavesdropping or man-in-the-middle types of attacks. Thus, the security policy must, be based on the assumption that the networks between the mobile device and the, organization are not trustworthy., USE OF APPLICATIONS CREATED BY UNKNOWN PARTIES By design, it is easy to find, and install third-party applications on mobile devices. This poses the obvious risk of, installing malicious software. An organization has several options for dealing with, this threat, as described subsequently., INTERACTION WITH OTHER SYSTEMS A common feature found on smartphones and, tablets is the ability to automatically synchronize data, apps, contacts, photos, and, so on with other computing devices and with cloud-based storage. Unless an organization has control of all the devices involved in synchronization, there is considerable risk of the organization’s data being stored in an unsecured location, plus the, risk of the introduction of malware., USE OF UNTRUSTED CONTENT Mobile devices may access and use content that other, computing devices do not encounter. An example is the Quick Response (QR), code, which is a two-dimensional barcode. QR codes are designed to be captured, by a mobile device camera and used by the mobile device. The QR code translates, to a URL, so that a malicious QR code could direct the mobile device to malicious, Web sites., USE OF LOCATION SERVICES The GPS capability on mobile devices can be used to, maintain a knowledge of the physical location of the device. While this feature, might be useful to an organization as part of a presence service, it creates security, risks. An attacker can use the location information to determine where the device, and user are located, which may be of use to the attacker., , Mobile Device Security Strategy, With the threats listed in the preceding discussion in mind, we outline the principal, elements of a mobile device security strategy. They fall into three categories: device, security, client/server traffic security, and barrier security (Figure 18.2)., DEVICE SECURITY A number of organizations will supply mobile devices for, employee use and preconfigure those devices to conform to the enterprise security policy. However, many organizations will find it convenient or even necessary, to adopt a bring-your-own-device (BYOD) policy that allows the personal mobile, devices of employees to have access to corporate resources. IT managers should be, able to inspect each device before allowing network access. IT will want to establish configuration guidelines for operating systems and applications. For example,, “rooted” or “jail-broken” devices are not permitted on the network, and mobile
Page 589 :
588, , CHAPTER 18 / WIRELESS NETWORK SECURITY, Mobile device is, configured with, security mechanisms and, parameters to conform to, organization security policy, , Mobile device, configuration, server, , Traffic is encrypted;, uses SSL or IPsec, VPN tunnel, , Application/, database, server, , Authentication/, access control, server, , Firewall, , Firewall limits, scope of data, and application, access, , Figure 18.2, , Authentication, and access control, protocols used to, verify device and user, and establish limits, on access, , Mobile Device Security Elements, , devices cannot store corporate contacts on local storage. Whether a device is owned, by the organization or BYOD, the organization should configure the device with, security controls, including the following:, ■, , ■, , ■, ■, ■, ■, ■, , Enable auto-lock, which causes the device to lock if it has not been used for a, given amount of time, requiring the user to re-enter a four-digit PIN or a password to re-activate the device., Enable password or PIN protection. The PIN or password is needed to unlock, the device. In addition, it can be configured so that email and other data on the, device are encrypted using the PIN or password and can only be retrieved with, the PIN or password., Avoid using auto-complete features that remember user names or passwords., Enable remote wipe., Ensure that SSL protection is enabled, if available., Make sure that software, including operating systems and applications, is up, to date., Install antivirus software as it becomes available.
Page 590 :
18.3 / IEEE 802.11 WIRELESS LAN OVERVIEW, ■, ■, ■, , ■, ■, , ■, , 589, , Either sensitive data should be prohibited from storage on the mobile device, or it should be encrypted., IT staff should also have the ability to remotely access devices, wipe the device, of all data, and then disable the device in the event of loss or theft., The organization may prohibit all installation of third-party applications,, implement whitelisting to prohibit installation of all unapproved applications,, or implement a secure sandbox that isolates the organization’s data and applications from all other data and applications on the mobile device. Any application that is on an approved list should be accompanied by a digital signature, and a public-key certificate from an approved authority., The organization can implement and enforce restrictions on what devices can, synchronize and on the use of cloud-based storage., To deal with the threat of untrusted content, security responses can include, training of personnel on the risks inherent in untrusted content and disabling, camera use on corporate mobile devices., To counter the threat of malicious use of location services, the security policy, can dictate that such service is disabled on all mobile devices., , TRAFFIC SECURITY Traffic security is based on the usual mechanisms for encryption, and authentication. All traffic should be encrypted and travel by secure means, such, as SSL or IPv6. Virtual private networks (VPNs) can be configured so that all traffic, between the mobile device and the organization’s network is via a VPN., A strong authentication protocol should be used to limit the access from the, device to the resources of the organization. Often, a mobile device has a single, device-specific authenticator, because it is assumed that the device has only one, user. A preferable strategy is to have a two-layer authentication mechanism, which, involves authenticating the device and then authenticating the user of the device., BARRIER SECURITY The organization should have security mechanisms to protect, the network from unauthorized access. The security strategy can also include firewall policies specific to mobile device traffic. Firewall policies can limit the scope, of data and application access for all mobile devices. Similarly, intrusion detection, and intrusion prevention systems can be configured to have tighter rules for mobile, device traffic., , 18.3 IEEE 802.11 WIRELESS LAN OVERVIEW, IEEE 802 is a committee that has developed standards for a wide range of local area, networks (LANs). In 1990, the IEEE 802 Committee formed a new working group,, IEEE 802.11, with a charter to develop a protocol and transmission specifications, for wireless LANs (WLANs). Since that time, the demand for WLANs at different, frequencies and data rates has exploded. Keeping pace with this demand, the IEEE, 802.11 working group has issued an ever-expanding list of standards. Table 18.1, briefly defines key terms used in the IEEE 802.11 standard.
Page 591 :
590, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , Table 18.1, , IEEE 802.11 Terminology, , Access point (AP), , Any entity that has station functionality and provides access to the, distribution system via the wireless medium for associated stations., , Basic service set (BSS), , A set of stations controlled by a single coordination function., , Coordination function, , The logical function that determines when a station operating within a BSS, is permitted to transmit and may be able to receive PDUs., , Distribution system (DS), , A system used to interconnect a set of BSSs and integrated LANs to create, an ESS., , Extended service set (ESS), , A set of one or more interconnected BSSs and integrated LANs that, appear as a single BSS to the LLC layer at any station associated with one, of these BSSs., , MAC protocol data unit, (MPDU), , The unit of data exchanged between two peer MAC entities using the, services of the physical layer., , MAC service data unit, (MSDU), , Information that is delivered as a unit between MAC users., , Station, , Any device that contains an IEEE 802.11 conformant MAC and physical, layer., , The Wi-Fi Alliance, The first 802.11 standard to gain broad industry acceptance was 802.11b. Although, 802.11b products are all based on the same standard, there is always a concern, whether products from different vendors will successfully interoperate. To meet, this concern, the Wireless Ethernet Compatibility Alliance (WECA), an industry consortium, was formed in 1999. This organization, subsequently renamed the, Wi-Fi (Wireless Fidelity) Alliance, created a test suite to certify interoperability for, 802.11b products. The term used for certified 802.11b products is Wi-Fi. Wi-Fi certification has been extended to 802.11g products. The Wi-Fi Alliance has also developed a certification process for 802.11a products, called Wi-Fi5. The Wi-Fi Alliance, is concerned with a range of market areas for WLANs, including enterprise, home,, and hot spots., More recently, the Wi-Fi Alliance has developed certification procedures for, IEEE 802.11 security standards, referred to as Wi-Fi Protected Access (WPA). The, most recent version of WPA, known as WPA2, incorporates all of the features of, the IEEE 802.11i WLAN security specification., , IEEE 802 Protocol Architecture, Before proceeding, we need to briefly preview the IEEE 802 protocol architecture., IEEE 802.11 standards are defined within the structure of a layered set of protocols., This structure, used for all IEEE 802 standards, is illustrated in Figure 18.3., PHYSICAL LAYER The lowest layer of the IEEE 802 reference model is the physical, layer, which includes such functions as encoding/decoding of signals and bit transmission/reception. In addition, the physical layer includes a specification of the, transmission medium. In the case of IEEE 802.11, the physical layer also defines, frequency bands and antenna characteristics.
Page 592 :
18.3 / IEEE 802.11 WIRELESS LAN OVERVIEW, General IEEE 802, functions, , Logical Link, Control, , Medium Access, Control, , Physical, , 591, , Specific IEEE 802.11, functions, , Flow control, Error control, , Assemble data into frame, Addressing, Error detection, Medium access, , Reliable data delivery, Wireless access control protocols, , Encoding/decoding of signals, Bit transmission/reception, Transmission medium, , Frequency band definition, Wireless signal encoding, , Figure 18.3 IEEE 802.11 Protocol Stack, , MEDIA ACCESS CONTROL All LANs consist of collections of devices that share the, network’s transmission capacity. Some means of controlling access to the transmission medium is needed to provide an orderly and efficient use of that capacity. This, is the function of a media access control (MAC) layer. The MAC layer receives data, from a higher-layer protocol, typically the Logical Link Control (LLC) layer, in the, form of a block of data known as the MAC service data unit (MSDU). In general,, the MAC layer performs the following functions:, ■, ■, ■, , On transmission, assemble data into a frame, known as a MAC protocol data, unit (MPDU) with address and error-detection fields., On reception, disassemble frame, and perform address recognition and error, detection., Govern access to the LAN transmission medium., , The exact format of the MPDU differs somewhat for the various MAC protocols in use. In general, all of the MPDUs have a format similar to that of Figure 18.4., The fields of this frame are as follows., ■, , ■, ■, , MAC Control: This field contains any protocol control information needed for, the functioning of the MAC protocol. For example, a priority level could be, indicated here., Destination MAC Address: The destination physical address on the LAN for, this MPDU., Source MAC Address: The source physical address on the LAN for this MPDU.
Page 593 :
592, , CHAPTER 18 / WIRELESS NETWORK SECURITY, MAC, Control, , Destination, MAC Address, , Source, MAC Address, , MAC Service Data Unit (MSDU), , MAC h ead er, , Figure 18.4, ■, ■, , CRC, , MAC tr ailer, , General IEEE 802 MPDU Format, , MAC Service Data Unit: The data from the next higher layer., CRC: The cyclic redundancy check field; also known as the Frame Check, Sequence (FCS) field. This is an error-detecting code, such as that which is, used in other data-link control protocols. The CRC is calculated based on the, bits in the entire MPDU. The sender calculates the CRC and adds it to the, frame. The receiver performs the same calculation on the incoming MPDU, and compares that calculation to the CRC field in that incoming MPDU. If, the two values don’t match, then one or more bits have been altered in transit., , The fields preceding the MSDU field are referred to as the MAC header, and, the field following the MSDU field is referred to as the MAC trailer. The header, and trailer contain control information that accompany the data field and that are, used by the MAC protocol., LOGICAL LINK CONTROL In most data-link control protocols, the data-link protocol, entity is responsible not only for detecting errors using the CRC, but for recovering, from those errors by retransmitting damaged frames. In the LAN protocol architecture, these two functions are split between the MAC and LLC layers. The MAC, layer is responsible for detecting errors and discarding any frames that contain errors. The LLC layer optionally keeps track of which frames have been successfully, received and retransmits unsuccessful frames., , IEEE 802.11 Network Components and Architectural Model, Figure 18.5 illustrates the model developed by the 802.11 working group. The smallest building block of a wireless LAN is a basic service set (BSS), which consists of, wireless stations executing the same MAC protocol and competing for access to the, same shared wireless medium. A BSS may be isolated, or it may connect to a backbone distribution system (DS) through an access point (AP). The AP functions as a, bridge and a relay point. In a BSS, client stations do not communicate directly with, one another. Rather, if one station in the BSS wants to communicate with another, station in the same BSS, the MAC frame is first sent from the originating station to, the AP and then from the AP to the destination station. Similarly, a MAC frame, from a station in the BSS to a remote station is sent from the local station to the AP, and then relayed by the AP over the DS on its way to the destination station. The, BSS generally corresponds to what is referred to as a cell in the literature. The DS, can be a switch, a wired network, or a wireless network., When all the stations in the BSS are mobile stations that communicate directly, with one another (not using an AP), the BSS is called an independent BSS (IBSS)., An IBSS is typically an ad hoc network. In an IBSS, the stations all communicate, directly, and no AP is involved.
Page 594 :
18.3 / IEEE 802.11 WIRELESS LAN OVERVIEW, , 593, , Distribution System, , AP 2, AP 1, Basic Service, Set (BSS), Basic Service, Set (BSS), , STA 1, STA 8, , STA 2, STA4, , STA 6, , STA 7, , STA 3, , Figure 18.5, , IEEE 802.11 Extended Service Set, , A simple configuration is shown in Figure 18.5, in which each station belongs, to a single BSS; that is, each station is within wireless range only of other stations, within the same BSS. It is also possible for two BSSs to overlap geographically, so, that a single station could participate in more than one BSS. Furthermore, the association between a station and a BSS is dynamic. Stations may turn off, come within, range, and go out of range., An extended service set (ESS) consists of two or more basic service sets, interconnected by a distribution system. The extended service set appears as a single logical LAN to the logical link control (LLC) level., , IEEE 802.11 Services, IEEE 802.11 defines nine services that need to be provided by the wireless LAN to, achieve functionality equivalent to that which is inherent to wired LANs. Table 18.2, lists the services and indicates two ways of categorizing them., 1. The service provider can be either the station or the DS. Station services are, implemented in every 802.11 station, including AP stations. Distribution services are provided between BSSs; these services may be implemented in an AP, or in another special-purpose device attached to the distribution system., 2. Three of the services are used to control IEEE 802.11 LAN access and confidentiality. Six of the services are used to support delivery of MSDUs between, stations. If the MSDU is too large to be transmitted in a single MPDU, it may, be fragmented and transmitted in a series of MPDUs.
Page 595 :
594, , CHAPTER 18 / WIRELESS NETWORK SECURITY, Table 18.2, , IEEE 802.11 Services, Service, , Provider, , Used to support, , Association, , Distribution system, , MSDU delivery, , Authentication, , Station, , LAN access and security, , Deauthentication, , Station, , LAN access and security, , Disassociation, , Distribution system, , MSDU delivery, , Distribution, , Distribution system, , MSDU delivery, , Integration, , Distribution system, , MSDU delivery, , MSDU delivery, , Station, , MSDU delivery, , Privacy, , Station, , LAN access and security, , Reassociation, , Distribution system, , MSDU delivery, , Following the IEEE 802.11 document, we next discuss the services in an order, designed to clarify the operation of an IEEE 802.11 ESS network. MSDU delivery,, which is the basic service, already has been mentioned. Services related to security, are introduced in Section 18.4., DISTRIBUTION OF MESSAGES WITHIN A DS The two services involved with the distribution of messages within a DS are distribution and integration. Distribution is, the primary service used by stations to exchange MPDUs when the MPDUs must, traverse the DS to get from a station in one BSS to a station in another BSS. For, example, suppose a frame is to be sent from station 2 (STA 2) to station 7 (STA 7), in Figure 18.5. The frame is sent from STA 2 to AP 1, which is the AP for this BSS., The AP gives the frame to the DS, which has the job of directing the frame to the, AP associated with STA 7 in the target BSS. AP 2 receives the frame and forwards, it to STA 7. How the message is transported through the DS is beyond the scope of, the IEEE 802.11 standard., If the two stations that are communicating are within the same BSS, then the, distribution service logically goes through the single AP of that BSS., The integration service enables transfer of data between a station on an IEEE, 802.11 LAN and a station on an integrated IEEE 802.x LAN. The term integrated, refers to a wired LAN that is physically connected to the DS and whose stations, may be logically connected to an IEEE 802.11 LAN via the integration service. The, integration service takes care of any address translation and media conversion logic, required for the exchange of data., ASSOCIATION-RELATED SERVICES The primary purpose of the MAC layer is to, transfer MSDUs between MAC entities; this purpose is fulfilled by the distribution service. For that service to function, it requires information about stations, within the ESS that is provided by the association-related services. Before the, distribution service can deliver data to or accept data from a station, that station must be associated. Before looking at the concept of association, we need
Page 596 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 595, , to describe the concept of mobility. The standard defines three transition types,, based on mobility:, ■, ■, , ■, , No transition: A station of this type is either stationary or moves only within, the direct communication range of the communicating stations of a single BSS., BSS transition: This is defined as a station movement from one BSS to another, BSS within the same ESS. In this case, delivery of data to the station requires that, the addressing capability be able to recognize the new location of the station., ESS transition: This is defined as a station movement from a BSS in one ESS, to a BSS within another ESS. This case is supported only in the sense that, the station can move. Maintenance of upper-layer connections supported by, 802.11 cannot be guaranteed. In fact, disruption of service is likely to occur., , To deliver a message within a DS, the distribution service needs to know where, the destination station is located. Specifically, the DS needs to know the identity of, the AP to which the message should be delivered in order for that message to reach, the destination station. To meet this requirement, a station must maintain an association with the AP within its current BSS. Three services relate to this requirement:, ■, , ■, ■, , Association: Establishes an initial association between a station and an AP., Before a station can transmit or receive frames on a wireless LAN, its identity and address must be known. For this purpose, a station must establish an, association with an AP within a particular BSS. The AP can then communicate, this information to other APs within the ESS to facilitate routing and delivery, of addressed frames., Reassociation: Enables an established association to be transferred from one, AP to another, allowing a mobile station to move from one BSS to another., Disassociation: A notification from either a station or an AP that an existing, association is terminated. A station should give this notification before leaving, an ESS or shutting down. However, the MAC management facility protects, itself against stations that disappear without notification., , 18.4 IEEE 802.11i WIRELESS LAN SECURITY, There are two characteristics of a wired LAN that are not inherent in a wireless LAN., 1. In order to transmit over a wired LAN, a station must be physically connected, to the LAN. On the other hand, with a wireless LAN, any station within radio, range of the other devices on the LAN can transmit. In a sense, there is a form, of authentication with a wired LAN in that it requires some positive and presumably observable action to connect a station to a wired LAN., 2. Similarly, in order to receive a transmission from a station that is part of a, wired LAN, the receiving station also must be attached to the wired LAN., On the other hand, with a wireless LAN, any station within radio range can, receive. Thus, a wired LAN provides a degree of privacy, limiting reception of, data to stations connected to the LAN., , Hiva-Network.Com
Page 597 :
596, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , These differences between wired and wireless LANs suggest the increased, need for robust security services and mechanisms for wireless LANs. The original, 802.11 specification included a set of security features for privacy and authentication that were quite weak. For privacy, 802.11 defined the Wired Equivalent, Privacy (WEP) algorithm. The privacy portion of the 802.11 standard contained, major weaknesses. Subsequent to the development of WEP, the 802.11i task, group has developed a set of capabilities to address the WLAN security issues., In order to accelerate the introduction of strong security into WLANs, the Wi-Fi, Alliance promulgated Wi-Fi Protected Access (WPA) as a Wi-Fi standard. WPA, is a set of security mechanisms that eliminates most 802.11 security issues and, was based on the current state of the 802.11i standard. The final form of the, 802.11i standard is referred to as Robust Security Network (RSN). The Wi-Fi, Alliance certifies vendors in compliance with the full 802.11i specification under, the WPA2 program., The RSN specification is quite complex, and occupies 145 pages of the 2012, IEEE 802.11 standard. In this section, we provide an overview., , IEEE 802.11i Services, The 802.11i RSN security specification defines the following services., ■, , ■, , ■, , Authentication: A protocol is used to define an exchange between a user and, an AS that provides mutual authentication and generates temporary keys to, be used between the client and the AP over the wireless link., Access control:1 This function enforces the use of the authentication function,, routes the messages properly, and facilitates key exchange. It can work with a, variety of authentication protocols., Privacy with message integrity: MAC-level data (e.g., an LLC PDU) are, encrypted along with a message integrity code that ensures that the data have, not been altered., , Figure 18.6a indicates the security protocols used to support these services,, while Figure 18.6b lists the cryptographic algorithms used for these services., , IEEE 802.11i Phases of Operation, The operation of an IEEE 802.11i RSN can be broken down into five distinct phases, of operation. The exact nature of the phases will depend on the configuration and, the end points of the communication. Possibilities include (see Figure 18.5):, 1. Two wireless stations in the same BSS communicating via the access point, (AP) for that BSS., 2. Two wireless stations (STAs) in the same ad hoc IBSS communicating directly, with each other., 1, , In this context, we are discussing access control as a security function. This is a different function than, media access control (MAC) as described in Section 18.3. Unfortunately, the literature and the standards, use the term access control in both contexts.
Page 598 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 597, , Services, , Access Control, , Authentication, and Key, Generation, , Protocols, , Robust Security Network (RSN), , IEEE 802.1, Port-based, Access Control, , Extensible, Authentication, Protocol (EAP), , Confidentiality, Data, Origin Authentication, and Integrity and, Replay Protection, TKIP, , CCMP, , (a) Services and protocols, , Algorithms, , Services, , Robust Security Network (RSN), , Confidentiality, , TKIP, (RC4), , CCM, (AESCTR), , NIST, Key, Wrap, , Integrity and, Data Origin, Authentication, TKIP, HMAC- HMAC(Michael, SHA-1, MD5, MIC), , Key, Generation, , CCM, (AESCBCMAC), , HMACSHA-1, , RFC, 1750, , (b) Cryptographic algorithms, CBC-MAC, CCM, CCMP, TKIP, , Figure 18.6, , =, =, =, =, , Cipher Block Chaining Message Authentication Code (MAC), Counter Mode with Cipher Block Chaining Message Authentication Code, Counter Mode with Cipher Block Chaining MAC Protocol, Temporal Key Integrity Protocol, , Elements of IEEE 802.11i, , 3. Two wireless stations in different BSSs communicating via their respective, APs across a distribution system., 4. A wireless station communicating with an end station on a wired network via, its AP and the distribution system., IEEE 802.11i security is concerned only with secure communication between, the STA and its AP. In case 1 in the preceding list, secure communication is assured, if each STA establishes secure communications with the AP. Case 2 is similar, with, the AP functionality residing in the STA. For case 3, security is not provided across, the distribution system at the level of IEEE 802.11, but only within each BSS. Endto-end security (if required) must be provided at a higher layer. Similarly, in case 4,, security is only provided between the STA and its AP.
Page 599 :
598, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , With these considerations in mind, Figure 18.7 depicts the five phases of operation for an RSN and maps them to the network components involved. One new, component is the authentication server (AS). The rectangles indicate the exchange, of sequences of MPDUs. The five phases are defined as follows., ■, , ■, , ■, , ■, , Discovery: An AP uses messages called Beacons and Probe Responses to advertise its IEEE 802.11i security policy. The STA uses these to identify an AP, for a WLAN with which it wishes to communicate. The STA associates with, the AP, which it uses to select the cipher suite and authentication mechanism, when the Beacons and Probe Responses present a choice., Authentication: During this phase, the STA and AS prove their identities to, each other. The AP blocks non-authentication traffic between the STA and AS, until the authentication transaction is successful. The AP does not participate, in the authentication transaction other than forwarding traffic between the, STA and AS., Key generation and distribution: The AP and the STA perform several operations that cause cryptographic keys to be generated and placed on the AP and, the STA. Frames are exchanged between the AP and STA only., Protected data transfer: Frames are exchanged between the STA and the end, station through the AP. As denoted by the shading and the encryption module, icon, secure data transfer occurs between the STA and the AP only; security is, not provided end-to-end., STA, , AP, , AS, , Phase 1 - Discovery, , Phase 2 - Authentication, , Phase 3 - Key Management, , Phase 4 - Protected Data Transfer, , Phase 5 - Connection Termination, , Figure 18.7, , IEEE 802.11i Phases of Operation, , End Station
Page 600 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, ■, , 599, , Connection termination: The AP and STA exchange frames. During this phase,, the secure connection is torn down and the connection is restored to the original state., , Discovery Phase, We now look in more detail at the RSN phases of operation, beginning with the, discovery phase, which is illustrated in the upper portion of Figure 18.8. The purpose of this phase is for an STA and an AP to recognize each other, agree on a set, of security capabilities, and establish an association for future communication using, those security capabilities., , STA, , Station sends a request, to join network, , AP, , Probe request, Probe response, , Station sends a, request to perform, null authentication, , Station sends a request to, associate with AP with, security parameters, , AS, , Open system, authentication request, Open system, authentication response, , AP sends possible, security parameter, (security capabilities set, per the security policy), , AP performs, null authentication, , Association request, Association response, , Station sets selected, security parameters, 802.1X-controlled port blocked, , AP sends the associated, security parameters, , 802.1X EAP request, 802.1X EAP response, Access request, (EAP request), Extensible Authentication Protocol Exchange, Accept/EAP-success, key material, 802.1X EAP success, 802.1X-controlled port blocked, , Figure 18.8, , IEEE 802.11i Phases of Operation: Capability Discovery,, Authentication, and Association
Page 601 :
600, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , SECURITY CAPABILITIES During this phase, the STA and AP decide on specific techniques in the following areas:, ■, ■, ■, , Confidentiality and MPDU integrity protocols for protecting unicast traffic, (traffic only between this STA and AP), Authentication method, Cryptography key management approach, , Confidentiality and integrity protocols for protecting multicast/broadcast traffic are dictated by the AP, since all STAs in a multicast group must use the same, protocols and ciphers. The specification of a protocol, along with the chosen key, length (if variable) is known as a cipher suite. The options for the confidentiality and, integrity cipher suite are, ■, ■, ■, ■, , WEP, with either a 40-bit or 104-bit key, which allows backward compatibility, with older IEEE 802.11 implementations, TKIP, CCMP, Vendor-specific methods, , The other negotiable suite is the authentication and key management (AKM), suite, which defines (1) the means by which the AP and STA perform mutual authentication and (2) the means for deriving a root key from which other keys may, be generated. The possible AKM suites are, ■, ■, ■, , IEEE 802.1X, Pre-shared key (no explicit authentication takes place and mutual authentication is implied if the STA and AP share a unique secret key), Vendor-specific methods, , MPDU EXCHANGE The discovery phase consists of three exchanges., ■, , ■, , ■, , Network and security capability discovery: During this exchange, STAs discover the existence of a network with which to communicate. The AP either, periodically broadcasts its security capabilities (not shown in figure), indicated, by RSN IE (Robust Security Network Information Element), in a specific, channel through the Beacon frame; or responds to a station’s Probe Request, through a Probe Response frame. A wireless station may discover available, access points and corresponding security capabilities by either passively monitoring the Beacon frames or actively probing every channel., Open system authentication: The purpose of this frame sequence, which provides no security, is simply to maintain backward compatibility with the IEEE, 802.11 state machine, as implemented in existing IEEE 802.11 hardware. In, essence, the two devices (STA and AP) simply exchange identifiers., Association: The purpose of this stage is to agree on a set of security capabilities to be used. The STA then sends an Association Request frame to, the AP. In this frame, the STA specifies one set of matching capabilities
Page 602 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 601, , (one authentication and key management suite, one pairwise cipher suite,, and one group-key cipher suite) from among those advertised by the AP., If there is no match in capabilities between the AP and the STA, the AP, refuses the Association Request. The STA blocks it too, in case it has associated with a rogue AP or someone is inserting frames illicitly on its channel., As shown in Figure 18.8, the IEEE 802.1X controlled ports are blocked, and, no user traffic goes beyond the AP. The concept of blocked ports is explained, subsequently., , Authentication Phase, As was mentioned, the authentication phase enables mutual authentication between, an STA and an authentication server (AS) located in the DS. Authentication is, designed to allow only authorized stations to use the network and to provide the, STA with assurance that it is communicating with a legitimate network., IEEE 802.1X ACCESS CONTROL APPROACH IEEE 802.11i makes use of another standard that was designed to provide access control functions for LANs. The standard, is IEEE 802.1X, Port-Based Network Access Control. The authentication protocol that is used, the Extensible Authentication Protocol (EAP), is defined in the, IEEE 802.1X standard. IEEE 802.1X uses the terms supplicant, authenticator, and, authentication server (AS). In the context of an 802.11 WLAN, the first two terms, correspond to the wireless station and the AP. The AS is typically a separate device, on the wired side of the network (i.e., accessible over the DS) but could also reside, directly on the authenticator., Before a supplicant is authenticated by the AS using an authentication protocol, the authenticator only passes control or authentication messages between the, supplicant and the AS; the 802.1X control channel is unblocked, but the 802.11 data, channel is blocked. Once a supplicant is authenticated and keys are provided, the, authenticator can forward data from the supplicant, subject to predefined access, control limitations for the supplicant to the network. Under these circumstances,, the data channel is unblocked., As indicated in Figure 16.5, 802.1X uses the concepts of controlled and uncontrolled ports. Ports are logical entities defined within the authenticator and refer to, physical network connections. For a WLAN, the authenticator (the AP) may have, only two physical ports: one connecting to the DS and one for wireless communication within its BSS. Each logical port is mapped to one of these two physical ports., An uncontrolled port allows the exchange of PDUs between the supplicant and the, other AS, regardless of the authentication state of the supplicant. A controlled port, allows the exchange of PDUs between a supplicant and other systems on the LAN, only if the current state of the supplicant authorizes such an exchange. IEEE 802.1X, is covered in more detail in Chapter 16., The 802.1X framework, with an upper-layer authentication protocol, fits, nicely with a BSS architecture that includes a number of wireless stations and an, AP. However, for an IBSS, there is no AP. For an IBSS, 802.11i provides a more, complex solution that, in essence, involves pairwise authentication between stations, on the IBSS.
Page 603 :
602, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , MPDU EXCHANGE The lower part of Figure 18.8 shows the MPDU exchange dictated by IEEE 802.11 for the authentication phase. We can think of authentication, phase as consisting of the following three phases., ■, , ■, ■, , Connect to AS: The STA sends a request to its AP (the one with which it has, an association) for connection to the AS. The AP acknowledges this request, and sends an access request to the AS., EAP exchange: This exchange authenticates the STA and AS to each other., A number of alternative exchanges are possible, as explained subsequently., Secure key delivery: Once authentication is established, the AS generates a, master session key (MSK), also known as the Authentication, Authorization,, and Accounting (AAA) key and sends it to the STA. As explained subsequently, all the cryptographic keys needed by the STA for secure communication with its AP are generated from this MSK. IEEE 802.11i does not prescribe a method for secure delivery of the MSK but relies on EAP for this., Whatever method is used, it involves the transmission of an MPDU containing, an encrypted MSK from the AS, via the AP, to the AS., , EAP EXCHANGE As mentioned, there are a number of possible EAP exchanges that, can be used during the authentication phase. Typically, the message flow between, STA and AP employs the EAP over LAN (EAPOL) protocol, and the message, flow between the AP and AS uses the Remote Authentication Dial In User Service, (RADIUS) protocol, although other options are available for both STA-to-AP and, AP-to-AS exchanges. [FRAN07] provides the following summary of the authentication exchange using EAPOL and RADIUS., 1. The EAP exchange begins with the AP issuing an EAP-Request/Identity, frame to the STA., 2. The STA replies with an EAP-Response/Identity frame, which the AP receives, over the uncontrolled port. The packet is then encapsulated in RADIUS over, EAP and passed on to the RADIUS server as a RADIUS-Access-Request packet., 3. The AAA server replies with a RADIUS-Access-Challenge packet, which is, passed on to the STA as an EAP-Request. This request is of the appropriate, authentication type and contains relevant challenge information., 4. The STA formulates an EAP-Response message and sends it to the AS. The, response is translated by the AP into a Radius-Access-Request with the response to the challenge as a data field. Steps 3 and 4 may be repeated multiple, times, depending on the EAP method in use. For TLS tunneling methods, it is, common for authentication to require 10 to 20 round trips., 5. The AAA server grants access with a Radius-Access-Accept packet. The AP, issues an EAP-Success frame. (Some protocols require confirmation of the, EAP success inside the TLS tunnel for authenticity validation.) The controlled, port is authorized, and the user may begin to access the network., Note from Figure 18.8 that the AP controlled port is still blocked to general, user traffic. Although the authentication is successful, the ports remain blocked
Page 604 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 603, , until the temporal keys are installed in the STA and AP, which occurs during the, 4-Way Handshake., , Key Management Phase, During the key management phase, a variety of cryptographic keys are generated, and distributed to STAs. There are two types of keys: pairwise keys used for communication between an STA and an AP and group keys used for multicast communication. Figure 18.9, based on [FRAN07], shows the two key hierarchies, and, Table 18.3 defines the individual keys., , Out-of-band path, , EAP method path, AAAK or MSK, , PSK, , Pre-shared key, User-defined, cryptoid, , 256 bits, , AAA key, ≥ 256 bits, , EAP, authentication, , PMK, , Legend, No modification, Possible truncation, PRF (pseudo random, function) using, HMAC-SHA-1, , Pairwise master key, 256 bits, , Following EAP authentication, or PSK, , PTK, , Pairwise transient key, During 4-way handshake, , 384 bits (CCMP), 512 bits (TKIP), KCK, , K EK, , EAPOL key confirmation key, , TK, , EAPOL key encryption key, 128 bits, , 128 bits, , Temporal key, 128 bits (CCMP), 256 bits (TKIP), , These keys are, components of the PTK, , (a) Pairwise key hierarchy, , GMK (generated by AS), , Group master key, 256 bits, , Changes periodically, or if compromised, , GTK, , Group temporal key, 40 bits, 104 bits (WEP), 128 bits (CCMP), 256 bits (TKIP), , Changes based on, policy (dissociation,, deauthentication), , (b) Group key hierarchy, , Figure 18.9, , IEEE 802.11i Key Hierarchies
Page 605 :
604, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , Table 18.3, , IEEE 802.11i Keys for Data Confidentiality and Integrity Protocols, , Abbreviation, , Name, , Description / Purpose, , Size (bits), , Type, , Ú 256, , Key generation key,, root key, , AAA Key, , Authentication,, Accounting, and, Authorization Key, , Used to derive the PMK., Used with the IEEE, 802.1X authentication, and key management, approach. Same as, MMSK., , PSK, , Pre-shared Key, , Becomes the PMK, in pre-shared key, environments., , 256, , Key generation key,, root key, , PMK, , Pairwise Master Key, , Used with other inputs to, derive the PTK., , 256, , Key generation key, , GMK, , Group Master Key, , Used with other inputs to, derive the GTK., , 128, , Key generation key, , PTK, , Pair-wise Transient, Key, , Derived from the PMK., Comprises the EAPOLKCK, EAPOL-KEK, and, TK and (for TKIP) the, MIC key., , 512 (TKIP), 384 (CCMP), , Composite key, , TK, , Temporal Key, , Used with TKIP or, CCMP to provide, confidentiality and, integrity protection for, unicast user traffic., , 256 (TKIP), 128 (CCMP), , Traffic key, , GTK, , Group Temporal Key, , Derived from the, GMK. Used to provide, confidentiality and, integrity protection for, multicast/broadcast user, traffic., , 256 (TKIP), 128 (CCMP), 40,104 (WEP), , Traffic key, , MIC Key, , Message Integrity, Code Key, , Used by TKIP’s Michael, MIC to provide integrity, protection of messages., , 64, , Message integrity key, , EAPOL-KCK, , EAPOL-Key, Confirmation Key, , Used to provide integrity, protection for key, material distributed, during the 4-Way, Handshake., , 128, , Message integrity key, , EAPOL-KEK, , EAPOL-Key, Encryption Key, , Used to ensure the, confidentiality of the, GTK and other key, material in the 4-Way, Handshake., , 128, , Traffic key / key, encryption key, , WEP Key, , Wired Equivalent, Privacy Key, , Used with WEP., , Hiva-Network.Com, , 40,104, , Traffic key
Page 606 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 605, , PAIRWISE KEYS Pairwise keys are used for communication between a pair of devices, typically between an STA and an AP. These keys form a hierarchy beginning, with a master key from which other keys are derived dynamically and used for a, limited period of time., At the top level of the hierarchy are two possibilities. A pre-shared key (PSK), is a secret key shared by the AP and a STA and installed in some fashion outside, the scope of IEEE 802.11i. The other alternative is the master session key (MSK),, also known as the AAAK, which is generated using the IEEE 802.1X protocol during the authentication phase, as described previously. The actual method of key, generation depends on the details of the authentication protocol used. In either case, (PSK or MSK), there is a unique key shared by the AP with each STA with which, it communicates. All the other keys derived from this master key are also unique, between an AP and an STA. Thus, each STA, at any time, has one set of keys, as, depicted in the hierarchy of Figure 18.9a, while the AP has one set of such keys for, each of its STAs., The pairwise master key (PMK) is derived from the master key. If a PSK is, used, then the PSK is used as the PMK; if a MSK is used, then the PMK is derived, from the MSK by truncation (if necessary). By the end of the authentication phase,, marked by the 802.1X EAP Success message (Figure 18.8), both the AP and the, STA have a copy of their shared PMK., The PMK is used to generate the pairwise transient key (PTK), which in fact, consists of three keys to be used for communication between an STA and AP after, they have been mutually authenticated. To derive the PTK, the HMAC-SHA-1, function is applied to the PMK, the MAC addresses of the STA and AP, and nonces, generated when needed. Using the STA and AP addresses in the generation of the, PTK provides protection against session hijacking and impersonation; using nonces, provides additional random keying material., The three parts of the PTK are as follows., ■, , ■, ■, , EAP Over LAN (EAPOL) Key Confirmation Key (EAPOL-KCK): Supports, the integrity and data origin authenticity of STA-to-AP control frames during, operational setup of an RSN. It also performs an access control function:, proof-of-possession of the PMK. An entity that possesses the PMK is authorized to use the link., EAPOL Key Encryption Key (EAPOL-KEK): Protects the confidentiality of, keys and other data during some RSN association procedures., Temporal Key (TK): Provides the actual protection for user traffic., , GROUP KEYS Group keys are used for multicast communication in which one STA, sends MPDU’s to multiple STAs. At the top level of the group key hierarchy is the, group master key (GMK). The GMK is a key-generating key used with other inputs, to derive the group temporal key (GTK). Unlike the PTK, which is generated using, material from both AP and STA, the GTK is generated by the AP and transmitted
Page 607 :
606, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , to its associated STAs. Exactly how this GTK is generated is undefined. IEEE, 802.11i, however, requires that its value is computationally indistinguishable from, random. The GTK is distributed securely using the pairwise keys that are already, established. The GTK is changed every time a device leaves the network., PAIRWISE KEY DISTRIBUTION The upper part of Figure 18.10 shows the MPDU, exchange for distributing pairwise keys. This exchange is known as the 4-way, handshake. The STA and AP use this handshake to confirm the existence of the, STA, , AP, , AP’s 802.1X-controlled port blocked, Message 1, EAPOL-key (Anonce, Unicast), Message 2 delivers another nonce to the, AP so that it can also generate the, PTK. It demonstrates to the AP that, the STA is alive, ensures that the, PTK is fresh (new) and that there is no, man-in-the-middle., , Message 4 serves as an acknowledgment to, Message 3. It serves no cryptographic, function. This message also ensures the, reliable start of the group key handshake., , Message 2, EAPOL-key (Snonce,, Unicast, MIC), Message 3, EAPOL-key (Install PTK,, Unicast, MIC), Message 4, EAPOL-key (Unicast, MIC), , Message 1 delivers a nonce to, the STA so that it can generate, the PTK., , Message 3 demonstrates to, the STA that the authenticator, is alive, ensures that the PTK is, fresh (new) and that there is no, man-in-the-middle., , AP’s 802.1X-controlled port, unblocked for unicast traffic, , The STA decrypts the GTK, and installs it for use., , Message 2 is delivered to the, AP. This frame serves only as, an acknowledgment to the AP., , Message 1, EAPOL-key (GTK, MIC), , Message 2, EAPOL-key (MIC), , Message 1 delivers a new GTK to, the STA. The GTK is encrypted, before it is sent and the entire, message is integrity protected., The AP installs the GTK., , Figure 18.10 IEEE 802.11i Phases of Operation: Four-Way Handshake and Group Key Handshake
Page 608 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 607, , PMK, verify the selection of the cipher suite, and derive a fresh PTK for the following data session. The four parts of the exchange are as follows., ■, ■, , ■, , ■, , AP S STA: Message includes the MAC address of the AP and a nonce, (Anonce), STA S AP: The STA generates its own nonce (Snonce) and uses both nonces, and both MAC addresses, plus the PMK, to generate a PTK. The STA then, sends a message containing its MAC address and Snonce, enabling the AP to, generate the same PTK. This message includes a message integrity code, (MIC)2 using HMAC-MD5 or HMAC-SHA-1-128. The key used with the MIC, is KCK., AP S STA: The AP is now able to generate the PTK. The AP then sends a, message to the STA, containing the same information as in the first message,, but this time including a MIC., STA S AP: This is merely an acknowledgment message, again protected by, a MIC., , GROUP KEY DISTRIBUTION For group key distribution, the AP generates a GTK and, distributes it to each STA in a multicast group. The two-message exchange with, each STA consists of the following:, ■, , ■, , AP S STA: This message includes the GTK, encrypted either with RC4 or, with AES. The key used for encryption is KEK, using a key wrapping algorithm (as discussed in Chapter 12). A MIC value is appended., STA S AP: The STA acknowledges receipt of the GTK. This message includes, a MIC value., , Protected Data Transfer Phase, IEEE 802.11i defines two schemes for protecting data transmitted in 802.11 MPDUs:, the Temporal Key Integrity Protocol (TKIP), and the Counter Mode-CBC MAC, Protocol (CCMP)., TKIP TKIP is designed to require only software changes to devices that are implemented with the older wireless LAN security approach called Wired Equivalent, Privacy (WEP). TKIP provides two services:, ■, , ■, , Message integrity: TKIP adds a message integrity code (MIC) to the 802.11, MAC frame after the data field. The MIC is generated by an algorithm, called, Michael, that computes a 64-bit value using as input the source and destination, MAC address values and the Data field, plus key material., Data confidentiality: Data confidentiality is provided by encrypting the, MPDU plus MIC value using RC4., , 2, While MAC is commonly used in cryptography to refer to a Message Authentication Code, the term, MIC is used instead in connection with 802.11i because MAC has another standard meaning, Media, Access Control, in networking.
Page 609 :
608, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , The 256-bit TK (Figure 18.9) is employed as follows. Two 64-bit keys are used, with the Michael message digest algorithm to produce a message integrity code., One key is used to protect STA-to-AP messages, and the other key is used to protect AP-to-STA messages. The remaining 128 bits are truncated to generate the, RC4 key used to encrypt the transmitted data., For additional protection, a monotonically increasing TKIP sequence counter, (TSC) is assigned to each frame. The TSC serves two purposes. First, the TSC is, included with each MPDU and is protected by the MIC to protect against replay, attacks. Second, the TSC is combined with the session TK to produce a dynamic encryption key that changes with each transmitted MPDU, thus making cryptanalysis, more difficult., CCMP CCMP is intended for newer IEEE 802.11 devices that are equipped with, the hardware to support this scheme. As with TKIP, CCMP provides two services:, ■, ■, , Message integrity: CCMP uses the cipher block chaining message authentication code (CBC-MAC), described in Chapter 12., Data confidentiality: CCMP uses the CTR block cipher mode of operation, with AES for encryption. CTR is described in Chapter 7., , The same 128-bit AES key is used for both integrity and confidentiality. The, scheme uses a 48-bit packet number to construct a nonce to prevent replay attacks., , The IEEE 802.11i Pseudorandom Function, At a number of places in the IEEE 802.11i scheme, a pseudorandom function (PRF) is, used. For example, it is used to generate nonces, to expand pairwise keys, and to generate the GTK. Best security practice dictates that different pseudorandom number, streams be used for these different purposes. However, for implementation efficiency,, we would like to rely on a single pseudorandom number generator function., The PRF is built on the use of HMAC-SHA-1 to generate a pseudorandom, bit stream. Recall that HMAC-SHA-1 takes a message (block of data) and a key of, length at least 160 bits and produces a 160-bit hash value. SHA-1 has the property, that the change of a single bit of the input produces a new hash value with no apparent connection to the preceding hash value. This property is the basis for pseudorandom number generation., The IEEE 802.11i PRF takes four parameters as input and produces the desired number of random bits. The function is of the form PRF(K, A, B, Len), where, K = a secret key, A = a text string specific to the application (e.g., nonce generation or pairwise, key expansion), B = some data specific to each case, Len = desired number of pseudorandom bits, For example, for the pairwise transient key for CCMP:, PTK = PRF (PMK, “Pairwise key expansion”, min (APAddr, STA-Addr) || max (AP-Addr, STA-Addr) || min, (Anonce, Snonce) || max (Anonce, Snonce), 384)
Page 610 :
18.4 / IEEE 802.11i WIRELESS LAN SECURITY, , 609, , So, in this case, the parameters are, K = PMK, A = the text string “Pairwise key expansion”, B = a sequence of bytes formed by concatenating the two MAC addresses, and the two nonces, Len = 384 bits, Similarly, a nonce is generated by, Nonce = PRF (Random Number, “InitCounter”, MAC || Time, 256), where Time is a measure of the network time known to the nonce generator., The group temporal key is generated by, GTK = PRF (GMK, “Group key expansion”, MAC || Gnonce, 256), Figure 18.11 illustrates the function PRF(K, A, B, Len). The parameter K, serves as the key input to HMAC. The message input consists of four items concatenated together: the parameter A, a byte with value 0, the parameter B, and a counter i. The counter is initialized to 0. The HMAC algorithm is run once, producing, a 160-bit hash value. If more bits are required, HMAC is run again with the same, inputs, except that i is incremented each time until the necessary number of bits is, generated. We can express the logic as, PRF (K, A, B, Len), null string, R, for i, 0 to ((Len + 159)/160 − 1) do, R, R || HMAC-SHA-1 (K, A || 0 || B || i), Return Truncate-to-Len (R, Len), S, , S, , S, , +1, A, , B, , 0, , i, , ||, , K, , HMAC-SHA-1, , R = HMAC-SHA-1(K, A || 0 || B || i), , Figure 18.11, , IEEE 802.11i Pseudorandom Function
Page 611 :
610, , CHAPTER 18 / WIRELESS NETWORK SECURITY, , 18.5 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, 4-way handshake, access point (AP), basic service set (BSS), Counter Mode-CBC MAC, Protocol (CCMP), distribution system (DS), extended service set (ESS), group keys, IEEE 802.1X, IEEE 802.11, IEEE 802.11i, , independent BSS (IBSS), logical link control (LLC), media access control (MAC), MAC protocol data unit, (MPDU), MAC service data unit, (MSDU), message integrity code, (MIC), Michael, pairwise keys, , pseudorandom function, Robust Security Network, (RSN), Temporal Key Integrity, Protocol (TKIP), Wi-Fi, Wi-Fi Protected Access, (WPA), Wired Equivalent Privacy, (WEP), Wireless LAN (WLAN), , Review Questions, 18.1, 18.2, 18.3, 18.4, 18.5, 18.6, 18.7, 18.8, , What is the basic building block of an 802.11 WLAN?, List and briefly define threats to a wireless network., List and briefly define IEEE 802.11 services., List some security threats related to mobile devices., How is the concept of an association related to that of mobility?, What security areas are addressed by IEEE 802.11i?, Briefly describe the five IEEE 802.11i phases of operation., What is the difference between TKIP and CCMP?, , Problems, 18.1, , 18.2, , In IEEE 802.11, open system authentication simply consists of two communications., An authentication is requested by the client, which contains the station ID (typically, the MAC address). This is followed by an authentication response from the AP/router, containing a success or failure message. An example of when a failure may occur is if, the client’s MAC address is explicitly excluded in the AP/router configuration., a. What are the benefits of this authentication scheme?, b. What are the security vulnerabilities of this authentication scheme?, Prior to the introduction of IEEE 802.11i, the security scheme for IEEE 802.11 was, Wired Equivalent Privacy (WEP). WEP assumed all devices in the network share a, secret key. The purpose of the authentication scenario is for the STA to prove that, it possesses the secret key. Authentication proceeds as shown in Figure 18.12. The, STA sends a message to the AP requesting authentication. The AP issues a challenge, which is a sequence of 128 random bytes sent as plaintext. The STA encrypts, the challenge with the shared key and returns it to the AP. The AP decrypts the, incoming value and compares it to the challenge that it sent. If there is a match, the, AP confirms that authentication has succeeded., a. What are the benefits of this authentication scheme?, b. This authentication scheme is incomplete. What is missing and why is this important? Hint: The addition of one or two messages would fix the problem., c. What is a cryptographic weakness of this scheme?
Page 612 :
18.5 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, STA, , Station sends a request, for authentication, , AP, , Request, , Challenge, Station responds, with encrypted version, of challenge number, , 611, , AP sends challenge message, containing 128-bit random, number, , Response, , Success, , AP decrypts challenge response., If match, send authentication, success message, , Figure 18.12 WEP Authentication; refer to Problem 18.2, 18.3, , 18.4, , For WEP, data integrity and data confidentiality are achieved using the RC4 stream, encryption algorithm. The transmitter of an MPDU performs the following steps,, referred to as encapsulation:, 1. The transmitter selects an initial vector (IV) value., 2. The IV value is concatenated with the WEP key shared by transmitter and receiver, to form the seed, or key input, to RC4., 3. A 32-bit cyclic redundancy check (CRC) is computed over all the bits of the MAC, data field and appended to the data field. The CRC is a common error-detection, code used in data link control protocols. In this case, the CRC serves as a integrity, check value (ICV)., 4. The result of step 3 is encrypted using RC4 to form the ciphertext block., 5. The plaintext IV is prepended to the ciphertext block to form the encapsulated, MPDU for transmission., a. Draw a block diagram that illustrates the encapsulation process., b. Describe the steps at the receiver end to recover the plaintext and perform the, integrity check., c. Draw a block diagram that illustrates part b., A potential weakness of the CRC as an integrity check is that it is a linear function., This means that you can predict which bits of the CRC are changed if a single bit of, the message is changed. Furthermore, it is possible to determine which combination, of bits could be flipped in the message so that the net result is no change in the CRC., Thus, there are a number of combinations of bit flippings of the plaintext message, that leave the CRC unchanged, so message integrity is defeated. However, in WEP,, if an attacker does not know the encryption key, the attacker does not have access to, the plaintext, only to the ciphertext block. Does this mean that the ICV is protected, from the bit flipping attack? Explain.
Page 613 :
CHAPTER, , Electronic Mail Security, 19.1 Internet Mail Architecture, Email Components, Email Protocols, 19.2 Email Formats, RFC 5322, Multipurpose Internet Mail Extensions, 19.3 Email Threats and Comprehensive Email Security, 19.4 S/MIME, Operational Description, S/MIME Message Content Types, Approved Cryptographic Algorithms, S/MIME Messages, S/MIME Certificate Processing, Enhanced Security Services, 19.5 Pretty Good Privacy, 19.6 DNSSEC, Domain Name System, DNS Security Extensions, 19.7 DNS-Based Authentication of Named Entities, TLSA Record, Use of DANE for SMTP, Use of DNSSEC for S/MIME, 19.8 Sender Policy Framework, SPF on the Sender Side, SPF on the Receiver Side, 19.9 DomainKeys Identified Mail, Email Threats, DKIM Strategy, DKIM Functional Flow, , 612
Page 614 :
19.1 / INTERNET MAIL ARCHITECTURE, , 613, , 19.10 Domain-Based Message Authentication, Reporting, and Conformance, Identifier Alignment, DMARC on the Sender Side, DMARC on the Receiver Side, DMARC Reports, 19.11 Key Terms, Review Questions, and Problems, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, ◆, ◆, ◆, ◆, ◆, , Summarize the key functional components of the Internet mail architecture., Explain the basic functionality of SMTP, POP3, and IMAP., Explain the need for MIME as an enhancement to ordinary email., Describe the key elements of MIME., Understand the functionality of S/MIME and the security threats it addresses., Understand the basic mechanisms of STARTTLS and its role in email, security., Understand the basic mechanisms of DANE and its role in email security., Understand the basic mechanisms of SPF and its role in email security., Understand the basic mechanisms of DKIM and its role in email security., Understand the basic mechanisms of DMARC and its role in email security., , In virtually all distributed environments, electronic mail is the most heavily used, network-based application. Users expect to be able to, and do, send email to others, who are connected directly or indirectly to the Internet, regardless of host operating system or communications suite. With the explosively growing reliance on email,, there grows a demand for authentication and confidentiality services. Two schemes, stand out as approaches that enjoy widespread use: Pretty Good Privacy (PGP) and, S/MIME. Both are examined in this chapter. This chapter concludes with a discussion, of DomainKeys Identified Mail., , 19.1 INTERNET MAIL ARCHITECTURE, For an understanding of the topics in this chapter, it is useful to have a basic grasp of, the Internet mail architecture, which is currently defined in RFC 5598 (Internet Mail, Architecture, July 2009). This section provides an overview of the basic concepts., , Hiva-Network.Com
Page 615 :
614, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , Email Components, At its most fundamental level, the Internet mail architecture consists of a user world, in the form of Message User Agents (MUA), and the transfer world, in the form, of the Message Handling Service (MHS), which is composed of Message Transfer, Agents (MTA). The MHS accepts a message from one user and delivers it to one, or more other users, creating a virtual MUA-to-MUA exchange environment. This, architecture involves three types of interoperability. One is directly between users:, messages must be formatted by the MUA on behalf of the message author so that, the message can be displayed to the message recipient by the destination MUA., There are also interoperability requirements between the MUA and the MHS—, first when a message is posted from an MUA to the MHS and later when it is delivered from the MHS to the destination MUA. Interoperability is required among the, MTA components along the transfer path through the MHS., Figure 19.1 illustrates the key components of the Internet mail architecture,, which include the following., ■, , Message User Agent (MUA): Operates on behalf of user actors and user, applications. It is their representative within the email service. Typically, this, function is housed in the user’s computer and is referred to as a client email, , Message transfer, agent (MTA), , SMTP, , Message transfer, agent (MTA), , SMTP, , Message transfer, agent (MTA), (SMTP,, local), , SMTP, Mail submission, agent (MSA), , Mail delivery, agent (MDA), , MESSAGE HANDLING, SYSTEM (MHS), , ESMTP, (Submission), , ESMTP, (Submission), , Message user, agent (MUA), , Message store, (MS), (IMAP, POP,, local), Message user, agent (MUA), , Message, author, , Message, recipient, , Figure 19.1, , Function Modules and Standardized Protocols Used between, them in the Internet Mail Architecture
Page 616 :
19.1 / INTERNET MAIL ARCHITECTURE, , ■, , ■, , ■, ■, , 615, , program or a local network email server. The author MUA formats a message, and performs initial submission into the MHS via a MSA. The recipient MUA, processes received mail for storage and/or display to the recipient user., Mail Submission Agent (MSA): Accepts the message submitted by an MUA, and enforces the policies of the hosting domain and the requirements of, Internet standards. This function may be located together with the MUA or, as a separate functional model. In the latter case, the Simple Mail Transfer, Protocol (SMTP) is used between the MUA and the MSA., Message Transfer Agent (MTA): Relays mail for one application-level hop. It, is like a packet switch or IP router in that its job is to make routing assessments, and to move the message closer to the recipients. Relaying is performed by a, sequence of MTAs until the message reaches a destination MDA. An MTA, also adds trace information to the message header. SMTP is used between, MTAs and between an MTA and an MSA or MDA., Mail Delivery Agent (MDA): Responsible for transferring the message from, the MHS to the MS., Message Store (MS): An MUA can employ a long-term MS. An MS can be, located on a remote server or on the same machine as the MUA. Typically,, an MUA retrieves messages from a remote server using POP (Post Office, Protocol) or IMAP (Internet Message Access Protocol)., , Two other concepts need to be defined. An administrative management, domain (ADMD) is an Internet email provider. Examples include a department that, operates a local mail relay (MTA), an IT department that operates an enterprise, mail relay, and an ISP that operates a public shared email service. Each ADMD, can have different operating policies and trust-based decision making. One obvious example is the distinction between mail that is exchanged within an organization and mail that is exchanged between independent organizations. The rules for, handling the two types of traffic tend to be quite different., The Domain Name System (DNS) is a directory lookup service that provides, a mapping between the name of a host on the Internet and its numerical address., DNS is discussed subsequently in this chapter., , Email Protocols, Two types of protocols are used for transferring email. The first type is used to move, messages through the Internet from source to destination. The protocol used for, this purpose is SMTP, with various extensions and in some cases restrictions. The, second type consists of protocols used to transfer messages between mail servers, of, which IMAP and POP are the most commonly used., SIMPLE MAIL TRANSFER PROTOCOL SMTP encapsulates an email message in an, envelope and is used to relay the encapsulated messages from source to destination, through multiple MTAs. SMTP was originally specified in 1982 as RFC 821 and has, undergone several revisions, the most current being RFC 5321 (October 2008). These, revisions have added additional commands and introduced extensions. The term, Extended SMTP (ESMTP) is often used to refer to these later versions of SMTP.
Page 617 : 616, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , SMTP is a text-based client-server protocol where the client (email sender), contacts the server (next-hop recipient) and issues a set of commands to tell the, server about the message to be sent, then sending the message itself. The majority, of these commands are ASCII text messages sent by the client and a resulting return, code (and additional ASCII text) returned by the server., The transfer of a message from a source to its ultimate destination can occur, over a single SMTP client/server conversation over a single TCP connection., Alternatively, an SMTP server may be an intermediate relay that assumes the role, of an SMTP client after receiving a message and then forwards that message to an, SMTP server along a route to the ultimate destination., The operation of SMTP consists of a series of commands and responses, exchanged between the SMTP sender and receiver. The initiative is with the SMTP, sender, who establishes the TCP connection. Once the connection is established,, the SMTP sender sends commands over the connection to the receiver. Each command consists of a single line of text, beginning with a four-letter command code, followed in some cases by an argument field. Each command generates exactly one, reply from the SMTP receiver. Most replies are a single-line, although multiple-line, replies are possible. Each reply begins with a three-digit code and may be followed, by additional information., Figure 19.2 illustrates the SMTP exchange between a client (C) and server (S)., The interchange begins with the client establishing a TCP connection to TCP port, 25 on the server (not shown in figure). This causes the server to activate SMTP, , S: 220 foo.com Simple Mail Transfer Service Ready, C: HELO bar.com, S: 250 OK, C: MAIL FROM:<
[email protected]>, S: 250 OK, C: RCPT TO:<
[email protected]>, S: 250 OK, C: RCPT TO:<
[email protected]>, S: 550 No such user here, C: RCPT TO:<
[email protected]>, S: 250 OK, C: DATA, S: 354 Start mail input; end with <crlf>.<crlf>, C: Blah blah blah . . ., C: . . . etc. etc. etc., C: <crlf><crlf>, S: 250 OK, C: QUIT, S: 221 foo.com Service closing transmission channel, , Figure 19.2, , Example SMTP Transaction Scenario
Page 618 : 19.2 / EMAIL FORMATS, , 617, , and send a 220 reply to the client. The HELO command identifies the sending, domain, which the server acknowledges and accepts with a 250 reply. The SMTP, sender is transmitting mail that originates with the user
[email protected]. The MAIL, command identifies the originator of the message. The message is addressed to, three users on machine foo.com, namely, Jones, Green, and Brown. The client identifies each of these in a separate RCPT command. The SMTP receiver indicates, that it has mailboxes for Jones and Brown but does not have information on Green., Because at least one of the intended recipients has been verified, the client proceeds, to send the text message, by first sending a DATA command to ensure the server, is ready for the data. After the server acknowledges receipt of all the data, it issues, a 250 OK message. Then the client issues a QUIT command and the server closes, the connection., A significant security-related extension for SMTP, called STARTTLS, is, defined in RFC 3207 (SMTP Service Extension for Secure SMTP over Transport, Layer Security, February 2002). STARTTLS enables the addition of confidentiality, and authentication in the exchange between SMTP agents. This gives SMTP agents, the ability to protect some or all of their communications from eavesdroppers, and attackers. If the client does initiate the connection over a TLS-enabled port, (e.g., port 465 was previously used for SMTP over SSL), the server may prompt with, a message indicating that the STARTTLS option is available. The client can then, issue the STARTTLS command in the SMTP command stream, and the two parties, proceed to establish a secure TLS connection. An advantage of using STARTTLS, is that the server can offer SMTP service on a single port, rather than requiring, separate port numbers for secure and cleartext operations. Similar mechanisms are, available for running TLS over IMAP and POP protocols., Historically, MUA/MSA message transfers have used SMTP. The standard, currently preferred is SUBMISSION, defined in RFC 6409 (Message Submission, for Mail, November 2011). Although SUBMISSION derives from SMTP, it uses a, separate TCP port and imposes distinct requirements, such as access authorization., MAIL ACCESS PROTOCOLS (POP3, IMAP) Post Office Protocol (POP3) allows an, email client (user agent) to download an email from an email server (MTA). POP3, user agents connect via TCP to the server (typically port 110). The user agent enters, a username and password (either stored internally for convenience or entered each, time by the user for stronger security). After authorization, the UA can issue POP3, commands to retrieve and delete mail., As with POP3, Internet Mail Access Protocol (IMAP) also enables an email, client to access mail on an email server. IMAP also uses TCP, with server TCP port, 143. IMAP is more complex than POP3. IMAP provides stronger authentication, than POP3 and provides other functions not supported by POP3., , 19.2 EMAIL FORMATS, To understand S/MIME, we need first to have a general understanding of the, underlying email format that it uses, namely, MIME. But to understand the significance of MIME, we need to go back to the traditional email format standard,
Page 619 : 618, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , RFC 822, which is still in common use. The most recent version of this format specification is RFC 5322 (Internet Message Format, October 2008). Accordingly, this, section first provides an introduction to these two earlier standards and then moves, on to a discussion of S/MIME., , RFC 5322, RFC 5322 defines a format for text messages that are sent using electronic mail. It, has been the standard for Internet-based text mail messages and remains in common use. In the RFC 5322 context, messages are viewed as having an envelope and, contents. The envelope contains whatever information is needed to accomplish, transmission and delivery. The contents compose the object to be delivered to the, recipient. The RFC 5322 standard applies only to the contents. However, the content standard includes a set of header fields that may be used by the mail system to, create the envelope, and the standard is intended to facilitate the acquisition of such, information by programs., The overall structure of a message that conforms to RFC 5322 is very simple., A message consists of some number of header lines (the header) followed by, unrestricted text (the body). The header is separated from the body by a blank line., Put differently, a message is ASCII text, and all lines up to the first blank line are, assumed to be header lines used by the user agent part of the mail system., A header line usually consists of a keyword, followed by a colon, followed by, the keyword’s arguments; the format allows a long line to be broken up into several, lines. The most frequently used keywords are From, To, Subject, and Date. Here is, an example message:, Date: October 8, 2009 2:15:49 PM EDT, From: “William Stallings” <
[email protected]>, Subject: The Syntax in RFC 5322, To:
[email protected], Cc:
[email protected], Hello. This section begins the actual, message body, which is delimited from the, message heading by a blank line., Another field that is commonly found in RFC 5322 headers is Message-ID., This field contains a unique identifier associated with this message., , Multipurpose Internet Mail Extensions, Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322, framework that is intended to address some of the problems and limitations of the, use of Simple Mail Transfer Protocol (SMTP) or some other mail transfer protocol, and RFC 5322 for electronic mail. RFCs 2045 through 2049 define MIME, and there, have been a number of updating documents since then.
Page 620 :
19.2 / EMAIL FORMATS, , 619, , As justification for the use of MIME, [PARZ06] lists the following limitations, of the SMTP/5322 scheme., 1. SMTP cannot transmit executable files or other binary objects. A number of, schemes are in use for converting binary files into a text form that can be used, by SMTP mail systems, including the popular UNIX UUencode/UUdecode, scheme. However, none of these is a standard or even a de facto standard., 2. SMTP cannot transmit text data that includes national language characters,, because these are represented by 8-bit codes with values of 128 decimal or, higher, and SMTP is limited to 7-bit ASCII., 3. SMTP servers may reject mail message over a certain size., 4. SMTP gateways that translate between ASCII and the character code EBCDIC, do not use a consistent set of mappings, resulting in translation problems., 5. SMTP gateways to X.400 electronic mail networks cannot handle nontextual, data included in X.400 messages., 6. Some SMTP implementations do not adhere completely to the SMTP, standards defined in RFC 821. Common problems include:, —Deletion, addition, or reordering of carriage return and linefeed, —Truncating or wrapping lines longer than 76 characters, —Removal of trailing white space (tab and space characters), —Padding of lines in a message to the same length, —Conversion of tab characters into multiple space characters, MIME is intended to resolve these problems in a manner that is compatible, with existing RFC 5322 implementations., OVERVIEW The MIME specification includes the following elements., 1. Five new message header fields are defined, which may be included in an, RFC 5322 header. These fields provide information about the body of the, message., 2. A number of content formats are defined, thus standardizing representations, that support multimedia electronic mail., 3. Transfer encodings are defined that enable the conversion of any content, format into a form that is protected from alteration by the mail system., In this subsection, we introduce the five message header fields. The next two, subsections deal with content formats and transfer encodings., The five header fields defined in MIME are as follows:, ■, ■, , MIME-Version: Must have the parameter value 1.0. This field indicates that, the message conforms to RFCs 2045 and 2046., Content-Type: Describes the data contained in the body with sufficient detail, that the receiving user agent can pick an appropriate agent or mechanism to, represent the data to the user or otherwise deal with the data in an appropriate, manner.
Page 621 :
620, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, ■, , Content-Transfer-Encoding: Indicates the type of transformation that has, been used to represent the body of the message in a way that is acceptable for, mail transport., Content-ID: Used to identify MIME entities uniquely in multiple contexts., Content-Description: A text description of the object with the body; this is, useful when the object is not readable (e.g., audio data)., , ■, ■, , Any or all of these fields may appear in a normal RFC 5322 header. A compliant implementation must support the MIME-Version, Content-Type, and ContentTransfer-Encoding fields; the Content-ID and Content-Description fields are, optional and may be ignored by the recipient implementation., MIME CONTENT TYPES The bulk of the MIME specification is concerned with, the definition of a variety of content types. This reflects the need to provide standardized ways of dealing with a wide variety of information representations in a, multimedia environment., Table 19.1 lists the content types specified in RFC 2046. There are seven different major types of content and a total of 15 subtypes. In general, a content type, declares the general type of data, and the subtype specifies a particular format for, that type of data., , Table 19.1, Type, Text, Multipart, , MIME Content Types, Subtype, Plain, Enriched, Mixed, , Parallel, Alternative, , Digest, Message, , Image, Video, Audio, Application, , rfc822, Partial, External-body, jpeg, gif, mpeg, Basic, PostScript, octet-stream, , Description, Unformatted text; may be ASCII or ISO 8859., Provides greater format flexibility., The different parts are independent but are to be transmitted, together. They should be presented to the receiver in the order, that they appear in the mail message., Differs from Mixed only in that no order is defined for delivering, the parts to the receiver., The different parts are alternative versions of the same, information. They are ordered in increasing faithfulness to the, original, and the recipient’s mail system should display the “best”, version to the user., Similar to Mixed, but the default type/subtype of each part is, message/rfc822., The body is itself an encapsulated message that conforms to RFC 822., Used to allow fragmentation of large mail items, in a way that is, transparent to the recipient., Contains a pointer to an object that exists elsewhere., The image is in JPEG format, JFIF encoding., The image is in GIF format., MPEG format., Single-channel 8-bit ISDN m-law encoding at a sample rate of, 8 kHz., Adobe Postscript format., General binary data consisting of 8-bit bytes.
Page 622 : 19.2 / EMAIL FORMATS, , 621, , For the text type of body, no special software is required to get the full meaning, of the text aside from support of the indicated character set. The primary subtype is, plain text, which is simply a string of ASCII characters or ISO 8859 characters. The, enriched subtype allows greater formatting flexibility., The multipart type indicates that the body contains multiple, independent, parts. The Content-Type header field includes a parameter (called boundary) that, defines the delimiter between body parts. This boundary should not appear in, any parts of the message. Each boundary starts on a new line and consists of two, hyphens followed by the boundary value. The final boundary, which indicates the, end of the last part, also has a suffix of two hyphens. Within each part, there may be, an optional ordinary MIME header., Here is a simple example of a multipart message containing two parts—both, consisting of simple text (taken from RFC 2046):, From: Nathaniel Borenstein <
[email protected]>, To: Ned Freed <
[email protected]>, Subject: Sample message, MIME-Version: 1.0, Content-type: multipart/mixed; boundary=“simple boundary”, This is the preamble. It is to be ignored, though it is a, handy place for mail composers to include an explanatory, note to non-MIME conformant readers., —simple boundary, This is implicitly typed plain ASCII text. It does NOT end, with a linebreak., —simple boundary, Content-type: text/plain; charset=us-ascii, This is explicitly typed plain ASCII text. It DOES end, with a linebreak., —simple boundary—, This is the epilogue. It is also to be ignored., There are four subtypes of the multipart type, all of which have the same, overall syntax. The multipart/mixed subtype is used when there are multiple independent body parts that need to be bundled in a particular order. For the multipart/, parallel subtype, the order of the parts is not significant. If the recipient’s system is, appropriate, the multiple parts can be presented in parallel. For example, a picture, or text part could be accompanied by a voice commentary that is played while the, picture or text is displayed., For the multipart/alternative subtype, the various parts are different representations of the same information. The following is an example:, From: Nathaniel Borenstein <
[email protected]>, To: Ned Freed <
[email protected]>, Subject: Formatted text mail
Page 623 :
622, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , MIME-Version: 1.0, Content-Type: multipart/alternative;, boundary=boundary42, —boundary42, Content-Type: text/plain; charset=us-ascii, . . . plain text version of message goes here. . . ., —boundary42, Content-Type: text/enriched, . . . RFC 1896 text/enriched version of same message, goes here . . ., —boundary42—, In this subtype, the body parts are ordered in terms of increasing preference., For this example, if the recipient system is capable of displaying the message in the, text/enriched format, this is done; otherwise, the plain text format is used., The multipart/digest subtype is used when each of the body parts is interpreted as an RFC 5322 message with headers. This subtype enables the construction, of a message whose parts are individual messages. For example, the moderator of a, group might collect email messages from participants, bundle these messages, and, send them out in one encapsulating MIME message., The message type provides a number of important capabilities in MIME., The message/rfc822 subtype indicates that the body is an entire message, including, header and body. Despite the name of this subtype, the encapsulated message may, be not only a simple RFC 5322 message, but also any MIME message., The message/partial subtype enables fragmentation of a large message into a, number of parts, which must be reassembled at the destination. For this subtype,, three parameters are specified in the Content-Type: Message/Partial field: an id, common to all fragments of the same message, a sequence number unique to each, fragment, and the total number of fragments., The message/external-body subtype indicates that the actual data to be conveyed in this message are not contained in the body. Instead, the body contains the, information needed to access the data. As with the other message types, the message/external-body subtype has an outer header and an encapsulated message with, its own header. The only necessary field in the outer header is the Content-Type, field, which identifies this as a message/external-body subtype. The inner header is, the message header for the encapsulated message. The Content-Type field in the, outer header must include an access-type parameter, which indicates the method of, access, such as FTP (file transfer protocol)., The application type refers to other kinds of data, typically either uninterpreted binary data or information to be processed by a mail-based application., MIME TRANSFER ENCODINGS The other major component of the MIME specification, in addition to content type specification, is a definition of transfer encodings, for message bodies. The objective is to provide reliable delivery across the largest, range of environments., , Hiva-Network.Com
Page 624 :
19.2 / EMAIL FORMATS, , 623, , The MIME standard defines two methods of encoding data. The ContentTransfer-Encoding field can actually take on six values, as listed in Table 19.2., However, three of these values (7-bit, 8-bit, and binary) indicate that no encoding has been done but provide some information about the nature of the data. For, SMTP transfer, it is safe to use the 7-bit form. The 8-bit and binary forms may be, usable in other mail transport contexts. Another Content-Transfer-Encoding value, is x-token, which indicates that some other encoding scheme is used for which, a name is to be supplied. This could be a vendor-specific or application-specific, scheme. The two actual encoding schemes defined are quoted-printable and base64., Two schemes are defined to provide a choice between a transfer technique that is, essentially human readable and one that is safe for all types of data in a way that is, reasonably compact., The quoted-printable transfer encoding is useful when the data consists largely, of octets that correspond to printable ASCII characters. In essence, it represents, nonsafe characters by the hexadecimal representation of their code and introduces, reversible (soft) line breaks to limit message lines to 76 characters., The base64 transfer encoding, also known as radix-64 encoding, is a common, one for encoding arbitrary binary data in such a way as to be invulnerable to the, processing by mail-transport programs. It is also used in PGP and is described in, Appendix X., A MULTIPART EXAMPLE Figure 19.3, taken from RFC 2045, is the outline of a complex multipart message. The message has five parts to be displayed serially: two, introductory plain text parts, an embedded multipart message, a richtext part, and, a closing encapsulated text message in a non-ASCII character set. The embedded, multipart message has two parts to be displayed in parallel: a picture and an audio, fragment., CANONICAL FORM An important concept in MIME and S/MIME is that of canonical, form. Canonical form is a format, appropriate to the content type, that is standardized for use between systems. This is in contrast to native form, which is a format that, may be peculiar to a particular system. RFC 2049 defines these two forms as follows:, ■, , Native form: The body to be transmitted is created in the system’s native format. The native character set is used and, where appropriate, local end-of-line, conventions are used as well. The body may be any format that corresponds to, , Table 19.2, , MIME Transfer Encodings, , 7 bit, , The data are all represented by short lines of ASCII characters., , 8 bit, , The lines are short, but there may be non-ASCII characters (octets with the, high-order bit set)., , binary, , Not only may non-ASCII characters be present but the lines are not necessarily, short enough for SMTP transport., , quoted-printable, , Encodes the data in such a way that if the data being encoded are mostly ASCII, text, the encoded form of the data remains largely recognizable by humans., , base64, , Encodes data by mapping 6-bit blocks of input to 8-bit blocks of output, all of, which are printable ASCII characters., , x-token, , A named nonstandard encoding.
Page 625 : 624, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , MIME-Version: 1.0, From: Nathaniel Borenstein <
[email protected]>, To: Ned Freed <
[email protected]>, Subject: A multipart example, Content-Type: multipart/mixed;, boundary=unique-boundary-1, This is the preamble area of a multipart message. Mail readers that, understand multipart format should ignore this preamble. If you are reading, this text, you might want to consider changing to a mail reader that, understands how to properly display multipart messages., —unique-boundary-1, . . . Some text appears here . . ., [Note that the preceding blank line means no header fields were given and, this is text, with charset US ASCII. It could have been done with explicit, typing as in the next part.], —unique-boundary-1, Content-type: text/plain; charset=US-ASCII, This could have been part of the previous part, but illustrates explicit, versus implicit typing of body parts., —unique-boundary-1, Content-Type: multipart/parallel; boundary=unique-boundary-2, —unique-boundary-2, Content-Type: audio/basic, Content-Transfer-Encoding: base64, . . . base64-encoded 8000 Hz single-channel mu-law-format audio data goes, here . . . ., —unique-boundary-2, Content-Type: image/jpeg, Content-Transfer-Encoding: base64, . . . base64-encoded image data goes here . . . ., —unique-boundary-2—, —unique-boundary-1, Content-type: text/enriched, This is richtext. as defined in RFC 1896, Isn’t it cool?, —unique-boundary-1, Content-Type: message/rfc822, From: (mailbox in US-ASCII), To: (address in US-ASCII), Subject: (subject in US-ASCII), Content-Type: Text/plain; charset=ISO-8859-1, Content-Transfer-Encoding: Quoted-printable, . . . Additional text in ISO-8859-1 goes here . . ., —unique-boundary-1—, , Figure 19.3 Example MIME Message Structure
Page 626 :
19.3 / EMAIL THREATS AND COMPREHENSIVE EMAIL SECURITY, , ■, , 625, , the local model for the representation of some form of information. Examples, include a UNIX-style text file, or a Sun raster image, or a VMS indexed file, and, audio data in a system-dependent format stored only in memory. In essence,, the data are created in the native form that corresponds to the type specified, by the media type., Canonical form: The entire body, including out-of-band information such as, record lengths and possibly file attribute information, is converted to a universal canonical form. The specific media type of the body as well as its associated, attributes dictates the nature of the canonical form that is used. Conversion to, the proper canonical form may involve character set conversion, transformation of audio data, compression, or various other operations specific to the, various media types., , 19.3 EMAIL THREATS AND COMPREHENSIVE EMAIL SECURITY, For both organizations and individuals, email is both pervasive and especially vulnerable to a wide range of security threats. In general terms, email security threats, can be classified as follows:, ■, ■, ■, ■, , Authenticity-related threats: Could result in unauthorized access to an enterprise’s email system., Integrity-related threats: Could result in unauthorized modification of email, content., Confidentiality-related threats: Could result in unauthorized disclosure of, sensitive information., Availability-related threats: Could prevent end users from being able to send, or receive email., , A useful list of specific email threats, together with approaches to mitigation,, is provided in NIST SP 800-177 (Trustworthy Email, September 2015) and is shown, in Table 19.3., SP 800-177 recommends use of a variety of standardized protocols as a means, for countering these threats. These include:, ■, , ■, , ■, , ■, , STARTTLS: An SMTP security extension that provides authentication, integrity, non-repudiation (via digital signatures) and confidentiality (via encryption) for the entire SMTP message by running SMTP over TLS., S/MIME: Provides authentication, integrity, non-repudiation (via digital, signatures) and confidentiality (via encryption) of the message body carried, in SMTP messages., DNS Security Extensions (DNSSEC): Provides authentication and integrity protection of DNS data, and is an underlying tool used by various email, security protocols., DNS-based Authentication of Named Entities (DANE): Is designed to overcome problems in the certificate authority (CA) system by providing an, alternative channel for authenticating public keys based on DNSSEC, with the
Page 627 :
626, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , Table 19.3, , Email Threats and Mitigations, , Threat, Email sent by, unauthorized MTA in, enterprise (e.g., malware, botnet), Email message sent, using spoofed or, unregistered sending, domain, Email message sent, using forged sending, address or email address, (i.e., phishing, spear, phishing), , Impact on Purported, Sender, Loss of reputation, valid, email from enterprise, may be blocked as, possible spam/phishing, attack., Loss of reputation, valid, email from enterprise, may be blocked as, possible spam/phishing, attack., Loss of reputation, valid, email from enterprise, may be blocked as, possible spam/phishing, attack., , Email modified in transit, , Leak of sensitive, information or PII., , Disclosure of sensitive, information (e.g., PII), via monitoring and, capturing of email traffic, Unsolicited Bulk Email, (UBE) (i.e., spam), , Leak of sensitive, information or PII., , DoS/DDoS attack, against an enterprises’, email servers, , ■, , ■, , ■, , None, unless purported, sender is spoofed., , Inability to send email., , Impact on Receiver, UBE and/or email, containing malicious, links may be delivered, into user inboxes., UBE and/or email, containing malicious, links may be delivered, into user inboxes., UBE and/or email, containing malicious, links may be delivered., Users may inadvertently, divulge sensitive, information or PII., Leak of sensitive, information, altered, message may contain, malicious information., Leak of sensitive, information, altered, message may contain, malicious information., UBE and/or email, containing malicious, links may be delivered, into user inboxes., Inability to receive, email., , Mitigation, Deployment of domainbased authentication, techniques. Use of, digital signatures over, email., Deployment of domainbased authentication, techniques. Use of, digital signatures over, email., Deployment of domainbased authentication, techniques. Use of, digital signatures over, email., Use of TLS to encrypt, email transfer between, servers. Use of end-toend email encryption., Use of TLS to encrypt, email transfer between, servers. Use of end-toend email encryption., Techniques to address, UBE., , Multiple mail servers,, use of cloud-based email, providers., , result that the same trust relationships used to certify IP addresses are used to, certify servers operating on those addresses., Sender Policy Framework (SPF): Uses the Domain Name System (DNS) to, allow domain owners to create records that associate the domain name with a, specific IP address range of authorized message senders. It is a simple matter, for receivers to check the SPF TXT record in the DNS to confirm that the purported sender of a message is permitted to use that source address and reject, mail that does not come from an authorized IP address., DomainKeys Identified Mail (DKIM): Enables an MTA to sign selected, headers and the body of a message. This validates the source domain of the, mail and provides message body integrity., Domain-based Message Authentication, Reporting, and Conformance, (DMARC): Lets senders know the proportionate effectiveness of their SPF, and DKIM policies, and signals to receivers what action should be taken in, various individual and bulk attack scenarios.
Page 628 :
19.4 / S/MIME, , 627, , DK, sen IM, din TX, to g M T R, Sender, rec TA R p, eiv ’s p ro, D, DNS, ing ub vid, M, A, M lic k es, TA ey, M RC, TA T, D th XT, K a, IM t s tell, s, DKIM, an end rec, d er, signature, SP us eivin, F es, g, , SP, se F T, nd, X, T, er, ’s, s, IP pec, ad fie, s, dr, es, s, , DNSSEC secured, , msg, msg, sig, , Sender, MUA, , Sending, MTA, , MTA’s DKIM, signing key, , Receiving, MTA, , sig, , R, AR, LS TP, T, SM ate, NE, DA cifies rtific, e, e, sp LS c, T, , sig, , Receiver, DNS, DNSSEC secured, , msg, , msg, , Sender’s S/MIME, signing key, (private key), , Receiver, MUA, Receiver MUA, verifies S/MIME, signature, , DANE = DNS-based Authentication of Named Entities, DKIM = DomainKeys Identified Mail, DMARC = Domain-based Message Authentication, Reporting, and Conformance, DNSSEC = Domain Name System Security Extensions, SPF = Sender Policy Framework, S/MIME = Secure Multi-Purpose Internet Mail Extensions, TLSA RR = Transport Layer Security Authentication Resource Record, , Figure 19.4 The Interrelationship of DNSSEC, SPF, DKIM, DMARC, DANE, and, S/MIME for Assuring Message Authenticity and Integrity, , Figure 19.4 shows how these components interact to provide message authenticity and integrity. Not shown, for simplicity, is that S/MIME also provides message, confidentiality by encrypting messages., , 19.4 S/MIME, Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement, to the MIME Internet email format standard based on technology from RSA Data, Security. S/MIME is a complex capability that is defined in a number of documents., The most important documents relevant to S/MIME include the following:, ■, , RFC 5750, S/MIME Version 3.2 Certificate Handling: Specifies conventions, for X.509 certificate usage by (S/MIME) v3.2.
Page 629 :
628, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, ■, ■, ■, ■, , ■, ■, ■, , RFC 5751, S/MIME) Version 3.2 Message Specification: The principal defining, document for S/MIME message creation and processing., RFC 4134, Examples of S/MIME Messages: Gives examples of message bodies, formatted using S/MIME., RFC 2634, Enhanced Security Services for S/MIME: Describes four optional, security service extensions for S/MIME., RFC 5652, Cryptographic Message Syntax (CMS): Describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest,, authenticate, or encrypt arbitrary message content., RFC 3370, CMS Algorithms: Describes the conventions for using several, cryptographic algorithms with the CMS., RFC 5752, Multiple Signatures in CMS: Describes the use of multiple, parallel, signatures for a message., RFC 1847, Security Multiparts for MIME—Multipart/Signed and Multipart/, Encrypted: Defines a framework within which security services may be applied, to MIME body parts. The use of a digital signature is relevant to S/MIME, as, explained subsequently., , Operational Description, S/MIME provides for four message-related services: authentication, confidentiality, compression, and email compatibility (Table 19.4). This subsection provides, an overview. We then look in more detail at this capability by examining message, formats and message preparation., AUTHENTICATION Authentication is provided by means of a digital signature, using, the general scheme discussed in Chapter 13 and illustrated in Figure 13.1. Most, commonly RSA with SHA-256 is used. The sequence is as follows:, 1. The sender creates a message., 2. SHA-256 is used to generate a 256-bit message digest of the message., Table 19.4 Summary of S/MIME Services, Function, , Typical Algorithm, , Digital signature, , RSA/SHA-256, , Message encryption, , AES-128 with CBC, , Compression, , unspecified, , Email compatibility, , Radix-64 conversion, , Typical Action, A hash code of a message is created using SHA-256., This message digest is encrypted using SHA-256, with the sender’s private key and included with, the message., A message is encrypted using AES-128 with CBC, with a one-time session key generated by the, sender. The session key is encrypted using RSA, with the recipient’s public key and included with, the message., A message may be compressed for storage or, transmission., To provide transparency for email applications, an, encrypted message may be converted to an ASCII, string using radix-64 conversion.
Page 630 :
19.4 / S/MIME, , 629, , 3. The message digest is encrypted with RSA using the sender’s private key, and, the result is appended to the message. Also appended is identifying information, for the signer, which will enable the receiver to retrieve the signer’s public key., 4. The receiver uses RSA with the sender’s public key to decrypt and recover the, message digest., 5. The receiver generates a new message digest for the message and compares, it with the decrypted hash code. If the two match, the message is accepted as, authentic., The combination of SHA-256 and RSA provides an effective digital signature, scheme. Because of the strength of RSA, the recipient is assured that only the possessor of the matching private key can generate the signature. Because of the strength, of SHA-256, the recipient is assured that no one else could generate a new message, that matches the hash code and, hence, the signature of the original message., Although signatures normally are found attached to the message or file that, they sign, this is not always the case: Detached signatures are supported. A detached, signature may be stored and transmitted separately from the message it signs. This, is useful in several contexts. A user may wish to maintain a separate signature log, of all messages sent or received. A detached signature of an executable program, can detect subsequent virus infection. Finally, detached signatures can be used, when more than one party must sign a document, such as a legal contract. Each, person’s signature is independent and therefore is applied only to the document., Otherwise, signatures would have to be nested, with the second signer signing both, the document and the first signature, and so on., CONFIDENTIALITY S/MIME provides confidentiality by encrypting messages. Most, commonly AES with a 128-bit key is used, with the cipher block chaining (CBC), mode. The key itself is also encrypted, typically with RSA, as explained below., As always, one must address the problem of key distribution. In S/MIME,, each symmetric key, referred to as a content-encryption key, is used only once. That, is, a new key is generated as a random number for each message. Because it is to be, used only once, the content-encryption key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver’s public key. The, sequence can be described as follows:, 1. The sender generates a message and a random 128-bit number to be used as a, content-encryption key for this message only., 2. The message is encrypted using the content-encryption key., 3. The content-encryption key is encrypted with RSA using the recipient’s public, key and is attached to the message., 4. The receiver uses RSA with its private key to decrypt and recover the, content-encryption key., 5. The content-encryption key is used to decrypt the message., Several observations may be made. First, to reduce encryption time, the combination of symmetric and public-key encryption is used in preference to simply, using public-key encryption to encrypt the message directly: Symmetric algorithms
Page 631 :
630, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , are substantially faster than asymmetric ones for a large block of content. Second,, the use of the public-key algorithm solves the session-key distribution problem,, because only the recipient is able to recover the session key that is bound to the, message. Note that we do not need a session-key exchange protocol of the type, discussed in Chapter 14, because we are not beginning an ongoing session. Rather,, each message is a one-time independent event with its own key. Furthermore, given, the store-and-forward nature of electronic mail, the use of handshaking to assure, that both sides have the same session key is not practical. Finally, the use of onetime symmetric keys strengthens what is already a strong symmetric encryption, approach. Only a small amount of plaintext is encrypted with each key, and there is, no relationship among the keys. Thus, to the extent that the public-key algorithm is, secure, the entire scheme is secure., CONFIDENTIALITY AND AUTHENTICATION As Figure 19.5 illustrates, both confidentiality and encryption may be used for the same message. The figure shows a, sequence in which a signature is generated for the plaintext message and appended, to the message. Then the plaintext message and signature are encrypted as a single, block using symmetric encryption and the symmetric encryption key is encrypted, using public-key encryption., S/MIME allows the signing and message encryption operations to be performed in either order. If signing is done first, the identity of the signer is hidden, by the encryption. Plus, it is generally more convenient to store a signature with a, plaintext version of a message. Furthermore, for purposes of third-party verification, if the signature is performed first, a third party need not be concerned with the, symmetric key when verifying the signature., If encryption is done first, it is possible to verify a signature without exposing, the message content. This can be useful in a context in which automatic signature, verification is desired, as no private key material is required to verify a signature., However, in this case the recipient cannot determine any relationship between the, signer and the unencrypted content of the message., EMAIL COMPATIBILITY When S/MIME is used, at least part of the block to be transmitted is encrypted. If only the signature service is used, then the message digest is, encrypted (with the sender’s private key). If the confidentiality service is used, the, message plus signature (if present) are encrypted (with a one-time symmetric key)., Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets., However, many electronic mail systems only permit the use of blocks consisting, of ASCII text. To accommodate this restriction, S/MIME provides the service of, converting the raw 8-bit binary stream to a stream of printable ASCII characters,, a process referred to as 7-bit encoding., The scheme typically used for this purpose is Base64 conversion. Each group, of three octets of binary data is mapped into four ASCII characters. See Appendix, X for a description., One noteworthy aspect of the Base64 algorithm is that it blindly converts the, input stream to Base64 format regardless of content, even if the input happens to, be ASCII text. Thus, if a message is signed but not encrypted and the conversion, is applied to the entire block, the output will be unreadable to the casual observer,, which provides a certain level of confidentiality.
Page 632 :
19.4 / S/MIME, , 631, , Receiver’s, public key, , One-time, secret key, Sender’s, private key, , msg, , Sign, (e.g., RSA/, SHA-256), , msg, , Encrypt, (e.g,, AES-128/, CBC, , sig, , Encrypt, (e.g., RSA), , msg, , sig, , (a) Sender signs, then encrypts message, Receiver’s, private key, , Sender’s, public key, , Secret key, generated by, sender, Decrypt, (e.g., RSA), msg, , Decrypt, (e.g,, AES-128/, CBC, , msg, , Verify, signature, (e.g., RSA/, SHA-256), , sig, , sig, , (b) Receiver decrypts message, then verifies sender’s signature, , Figure 19.5, , Simplified S/MIME Functional Flow, , RFC 5751 also recommends that even if outer 7-bit encoding is not used, the, original MIME content should be 7-bit encoded. The reason for this is that it allows, the MIME entity to be handled in any environment without changing it. For example, a trusted gateway might remove the encryption, but not the signature, of a message, and then forward the signed message on to the end recipient so that they can, verify the signatures directly. If the transport internal to the site is not 8-bit clean,, such as on a wide area network with a single mail gateway, verifying the signature, will not be possible unless the original MIME entity was only 7-bit data., COMPRESSION S/MIME also offers the ability to compress a message. This has the, benefit of saving space both for email transmission and for file storage. Compression, , Hiva-Network.Com
Page 633 :
632, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , can be applied in any order with respect to the signing and message encryption, operations. RFC 5751 provides the following guidelines:, ■, , ■, , Compression of binary encoded encrypted data is discouraged, since it will not, yield significant compression. Base64 encrypted data could very well benefit,, however., If a lossy compression algorithm is used with signing, you will need to compress, first, then sign., , S/MIME Message Content Types, S/MIME uses the following message content types, which are defined in RFC 5652,, Cryptographic Message Syntax:, ■, , ■, ■, ■, , Data: Refers to the inner MIME-encoded message content, which may then, be encapsulated in a SignedData, EnvelopedData, or CompressedData content type., SignedData: Used to apply a digital signature to a message., EnvelopedData: This consists of encrypted content of any type and encryptedcontent encryption keys for one or more recipients., CompressedData: Used to apply data compression to a message., , The Data content type is also used for a procedure known as clear signing., For clear signing, a digital signature is calculated for a MIME-encoded message and, the two parts, the message and signature, form a multipart MIME message. Unlike, SignedData, which involves encapsulating the message and signature in a special, format, clear-signed messages can be read and their signatures verified by email, entities that do not implement S/MIME., , Approved Cryptographic Algorithms, Table 19.5 summarizes the cryptographic algorithms used in S/MIME. S/MIME, uses the following terminology taken from RFC 2119 (Key Words for use in RFCs to, Indicate Requirement Levels, March 1997) to specify the requirement level:, ■, , ■, , MUST: The definition is an absolute requirement of the specification. An, implementation must include this feature or function to be in conformance, with the specification., SHOULD: There may exist valid reasons in particular circumstances to ignore, this feature or function, but it is recommended that an implementation include, the feature or function., , The S/MIME specification includes a discussion of the procedure for deciding, which content encryption algorithm to use. In essence, a sending agent has two decisions to make. First, the sending agent must determine if the receiving agent is capable, of decrypting using a given encryption algorithm. Second, if the receiving agent is only, capable of accepting weakly encrypted content, the sending agent must decide if it is, acceptable to send using weak encryption. To support this decision process, a sending, agent may announce its decrypting capabilities in order of preference for any message, that it sends out. A receiving agent may store that information for future use.
Page 634 :
19.4 / S/MIME, Table 19.5, , 633, , Cryptographic Algorithms Used in S/MIME, Function, , Create a message digest to be used in, forming a digital signature., , Use message digest to form a digital, signature., , Encrypt session key for transmission with, a message., , Encrypt message for transmission with a, one-time session key., , Requirement, MUST support SHA-256, SHOULD support SHA-1, Receiver SHOULD support MD5 for backward compatibility, MUST support RSA with SHA-256, SHOULD support, —DSA with SHA-256, —RSASSA-PSS with SHA-256, —RSA with SHA-1, —DSA with SHA-1, —RSA with MD5, MUST support RSA encryption, SHOULD support, —RSAES-OAEP, —Diffie–Hellman ephemeral-static mode, MUST support AES-128 with CBC, SHOULD support, —AES-192 CBC and AES-256 CBC, —Triple DES CBC, , The following rules, in the following order, should be followed by a sending agent., 1. If the sending agent has a list of preferred decrypting capabilities from an, intended recipient, it SHOULD choose the first (highest preference) capability on the list that it is capable of using., 2. If the sending agent has no such list of capabilities from an intended recipient, but has received one or more messages from the recipient, then the outgoing, message SHOULD use the same encryption algorithm as was used on the last, signed and encrypted message received from that intended recipient., 3. If the sending agent has no knowledge about the decryption capabilities of the, intended recipient and is willing to risk that the recipient may not be able to, decrypt the message, then the sending agent SHOULD use triple DES., 4. If the sending agent has no knowledge about the decryption capabilities of the, intended recipient and is not willing to risk that the recipient may not be able, to decrypt the message, then the sending agent MUST use RC2/40., If a message is to be sent to multiple recipients and a common encryption, algorithm cannot be selected for all, then the sending agent will need to send two, messages. However, in that case, it is important to note that the security of the, message is made vulnerable by the transmission of one copy with lower security., , S/MIME Messages, S/MIME makes use of a number of new MIME content types. All of the new application types use the designation PKCS. This refers to a set of public-key cryptography, specifications issued by RSA Laboratories and made available for the S/MIME effort.
Page 635 :
634, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , We examine each of these in turn after first looking at the general procedures, for S/MIME message preparation., SECURING A MIME ENTITY S/MIME secures a MIME entity with a signature,, encryption, or both. A MIME entity may be an entire message (except for the RFC, 5322 headers), or if the MIME content type is multipart, then a MIME entity is one, or more of the subparts of the message. The MIME entity is prepared according, to the normal rules for MIME message preparation. Then the MIME entity plus, some security-related data, such as algorithm identifiers and certificates, are processed by S/MIME to produce what is known as a PKCS object. A PKCS object is, then treated as message content and wrapped in MIME (provided with appropriate, MIME headers). This process should become clear as we look at specific objects, and provide examples., In all cases, the message to be sent is converted to canonical form. In particular, for a given type and subtype, the appropriate canonical form is used for the, message content. For a multipart message, the appropriate canonical form is used, for each subpart., The use of transfer encoding requires special attention. For most cases, the, result of applying the security algorithm will be to produce an object that is partially, or totally represented in arbitrary binary data. This will then be wrapped in an outer, MIME message and transfer encoding can be applied at that point, typically base64., However, in the case of a multipart signed message (described in more detail later),, the message content in one of the subparts is unchanged by the security process., Unless that content is 7 bit, it should be transfer encoded using base64 or quotedprintable so that there is no danger of altering the content to which the signature, was applied., We now look at each of the S/MIME content types., ENVELOPEDDATA An application/pkcs7-mime subtype is used for one of four categories of S/MIME processing, each with a unique smime-type parameter. In all, cases, the resulting entity, (referred to as an object) is represented in a form known, as Basic Encoding Rules (BER), which is defined in ITU-T Recommendation, X.209. The BER format consists of arbitrary octet strings and is therefore binary, data. Such an object should be transfer encoded with base64 in the outer MIME, message. We first look at envelopedData., The steps for preparing an envelopedData MIME entity are:, 1. Generate a pseudorandom session key for a particular symmetric encryption, algorithm (RC2/40 or triple DES)., 2. For each recipient, encrypt the session key with the recipient’s public RSA key., 3. For each recipient, prepare a block known as RecipientInfo that contains, an identifier of the recipient’s public-key certificate, 1 an identifier of the, algorithm used to encrypt the session key, and the encrypted session key., 4. Encrypt the message content with the session key., 1, , This is an X.509 certificate, discussed later in this section.
Page 636 :
19.4 / S/MIME, , 635, , The RecipientInfo blocks followed by the encrypted content constitute the, envelopedData. This information is then encoded into base64. A sample message, (excluding the RFC 5322 headers) is given below., Content-Type: application/pkcs7-mime; smime-type=envelopeddata; name=smime.p7m, Content-Transfer-Encoding: base64, Content-Disposition: attachment; filename=smime.p7m, rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6, 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H, f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4, 0GhIGfHfQbnj756YT64V, To recover the encrypted message, the recipient first strips off the base64, encoding. Then the recipient’s private key is used to recover the session key. Finally,, the message content is decrypted with the session key., SIGNEDDATA The signedData smime-type can be used with one or more signers., For clarity, we confine our description to the case of a single digital signature. The, steps for preparing a signedData MIME entity are as follows., 1., 2., 3., 4., , Select a message digest algorithm (SHA or MD5)., Compute the message digest (hash function) of the content to be signed., Encrypt the message digest with the signer’s private key., Prepare a block known as SignerInfo that contains the signer’s public-key, certificate, an identifier of the message digest algorithm, an identifier of the, algorithm used to encrypt the message digest, and the encrypted message, digest., , The signedData entity consists of a series of blocks, including a message, digest algorithm identifier, the message being signed, and SignerInfo. The, signedData entity may also include a set of public-key certificates sufficient to, constitute a chain from a recognized root or top-level certification authority to the, signer. This information is then encoded into base64. A sample message (excluding, the RFC 5322 headers) is the following., Content-Type: application/pkcs7-mime; smime-type=signeddata; name=smime.p7m, Content-Transfer-Encoding: base64, Content-Disposition: attachment; filename=smime.p7m, 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7, 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH, HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh, 6YT64V0GhIGfHfQbnj75
Page 637 :
636, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , To recover the signed message and verify the signature, the recipient first strips, off the base64 encoding. Then the signer’s public key is used to decrypt the message, digest. The recipient independently computes the message digest and compares it to, the decrypted message digest to verify the signature., CLEAR SIGNING Clear signing is achieved using the multipart content type with, a signed subtype. As was mentioned, this signing process does not involve transforming the message to be signed, so that the message is sent “in the clear.” Thus,, recipients with MIME capability but not S/MIME capability are able to read the, incoming message., A multipart/signed message has two parts. The first part can be any MIME, type but must be prepared so that it will not be altered during transfer from source, to destination. This means that if the first part is not 7 bit, then it needs to be encoded, using base64 or quoted-printable. Then this part is processed in the same manner, as signedData, but in this case an object with signedData format is created that, has an empty message content field. This object is a detached signature. It is then, transfer encoded using base64 to become the second part of the multipart/signed, message. This second part has a MIME content type of application and a subtype of, pkcs7-signature. Here is a sample message:, Content-Type: multipart/signed;, protocol=”application/pkcs7-signature”;, micalg=sha1; boundary=boundary42, —boundary42, Content-Type: text/plain, This is a clear-signed message., —boundary42, Content-Type: application/pkcs7-signature; name=smime.p7s, Content-Transfer-Encoding: base64, Content-Disposition: attachment; filename=smime.p7s, ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6, 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj, n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4, 7GhIGfHfYT64VQbnj756, —boundary42—, The protocol parameter indicates that this is a two-part clear-signed entity., The micalg parameter indicates the type of message digest used. The receiver can, verify the signature by taking the message digest of the first part and comparing this, to the message digest recovered from the signature in the second part., REGISTRATION REQUEST Typically, an application or user will apply to a certification authority for a public-key certificate. The application/pkcs10 S/MIME
Page 638 :
19.4 / S/MIME, , 637, , entity is used to transfer a certification request. The certification request, includes certificationRequestInfo block, followed by an identifier, of the public-key encryption algorithm, followed by the signature of the, certificationRequestInfo block, made using the sender’s private key. The, certificationRequestInfo block includes a name of the certificate subject, (the entity whose public key is to be certified) and a bit-string representation of the, user’s public key., CERTIFICATES-ONLY MESSAGE A message containing only certificates or a certificate, revocation list (CRL) can be sent in response to a registration request. The message, is an application/pkcs7-mime type/subtype with an smime-type parameter of degenerate. The steps involved are the same as those for creating a signedData message,, except that there is no message content and the signerInfo field is empty., , S/MIME Certificate Processing, S/MIME uses public-key certificates that conform to version 3 of X.509 (see, Chapter 14). S/MIME managers and/or users must configure each client with a list of, trusted keys and with certificate revocation lists. That is, the responsibility is local for, maintaining the certificates needed to verify incoming signatures and to encrypt outgoing messages. On the other hand, the certificates are signed by certification authorities., USER AGENT ROLE An S/MIME user has several key management functions to, perform., ■, , ■, ■, , Key generation: The user of some related administrative utility (e.g., one, associated with LAN management) MUST be capable of generating separate, Diffie–Hellman and DSS key pairs and SHOULD be capable of generating, RSA key pairs. Each key pair MUST be generated from a good source of, nondeterministic random input and be protected in a secure fashion. A user, agent SHOULD generate RSA key pairs with a length in the range of 768 to, 1024 bits and MUST NOT generate a length of less than 512 bits., Registration: A user’s public key must be registered with a certification, authority in order to receive an X.509 public-key certificate., Certificate storage and retrieval: A user requires access to a local list of certificates in order to verify incoming signatures and to encrypt outgoing messages., Such a list could be maintained by the user or by some local administrative, entity on behalf of a number of users., , Enhanced Security Services, RFC 2634 defines four enhanced security services for S/MIME:, ■, , Signed receipts: A signed receipt may be requested in a SignedData object., Returning a signed receipt provides proof of delivery to the originator of a, message and allows the originator to demonstrate to a third party that the, recipient received the message. In essence, the recipient signs the entire, original message plus the original (sender’s) signature and appends the new, signature to form a new S/MIME message.
Page 639 :
638, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, ■, , ■, , ■, , Security labels: A security label may be included in the authenticated attributes, of a SignedData object. A security label is a set of security information, regarding the sensitivity of the content that is protected by S/MIME encapsulation. The labels may be used for access control, by indicating which users are, permitted access to an object. Other uses include priority (secret, confidential,, restricted, and so on) or role based, describing which kind of people can see, the information (e.g., patient’s health-care team, medical billing agents)., Secure mailing lists: When a user sends a message to multiple recipients, a, certain amount of per-recipient processing is required, including the use of, each recipient’s public key. The user can be relieved of this work by employing the services of an S/MIME Mail List Agent (MLA). An MLA can take a, single incoming message, perform the recipient-specific encryption for each, recipient, and forward the message. The originator of a message need only, send the message to the MLA with encryption performed using the MLA’s, public key., Signing certificates: This service is used to securely bind a sender’s certificate, to their signature through a signing certificate attribute., , 19.5 PRETTY GOOD PRIVACY, An alternative email security protocol is Pretty Good Privacy (PGP), which has, essentially the same functionality as S/MIME. PGP was created by Phil Zimmerman, and implemented as a product first released in 1991. It was made available free of, charge and became quite popular for personal use. The initial PGP protocol was, proprietary and used some encryption algorithms with intellectual property restrictions. In 1996, version 5.x of PGP was defined in IETF RFC 1991, PGP Message, Exchange Formats. Subsequently, OpenPGP was developed as a new standard, protocol based on PGP version 5.x. OpenPGP is defined in RFC 4880 (OpenPGP, Message Format, November 2007) and RFC 3156 (MIME Security with OpenPGP,, August 2001)., There are two significant differences between S/MIME and OpenPGP:, ■, , ■, , Key Certification: S/MIME uses X.509 certificates that are issued by Certificate, Authorities (or local agencies that have been delegated authority by a CA to, issue certificates). In OpenPGP, users generate their own OpenPGP public, and private keys and then solicit signatures for their public keys from individuals or organizations to which they are known. Whereas X.509 certificates are, trusted if there is a valid PKIX chain to a trusted root, an OpenPGP public key, is trusted if it is signed by another OpenPGP public key that is trusted by the, recipient. This is called the Web-of-Trust., Key Distribution: OpenPGP does not include the sender’s public key with, each message, so it is necessary for recipients of OpenPGP messages to separately obtain the sender’s public key in order to verify the message. Many, organizations post OpenPGP keys on TLS-protected websites: People who, wish to verify digital signatures or send these organizations encrypted mail
Page 640 :
19.6 / DNSSEC, , 639, , need to manually download these keys and add them to their OpenPGP, clients. Keys may also be registered with the OpenPGP public key servers,, which are servers that maintain a database of PGP public keys organized by, email address. Anyone may post a public key to the OpenPGP key servers,, and that public key may contain any email address. There is no vetting of, OpenPGP keys, so users must use the Web-of-Trust to decide whether to trust, a given public key., NIST 800-177 recommends the use of S/MIME rather than PGP because of, the greater confidence in the CA system of verifying public keys., Appendix P provides an overview of PGP., , 19.6 DNSSEC, DNS Security Extensions (DNSSEC) are used by several protocols that provide, email security. This section provides a brief overview of the Domain Name System, (DNS) and then looks at DNSSEC., , Domain Name System, DNS is a directory lookup service that provides a mapping between the name of a, host on the Internet and its numeric IP address. DNS is essential to the functioning, of the Internet. The DNS is used by MUAs and MTAs to find the address of the, next hop server for mail delivery. Sending MTAs query DNS for the Mail Exchange, Resource Record (MX RR) of the recipient’s domain (the right hand side of the, “@” symbol) in order to find the receiving MTA to contact., Four elements comprise the DNS:, ■, ■, , ■, ■, , Domain name space: DNS uses a tree-structured name space to identify, resources on the Internet., DNS database: Conceptually, each node and leaf in the name space tree structure names a set of information (e.g., IP address, name server for this domain, name) that is contained in resource record. The collection of all RRs is organized into a distributed database., Name servers: These are server programs that hold information about a portion of the domain name tree structure and the associated RRs., Resolvers: These are programs that extract information from name servers in, response to client requests. A typical client request is for an IP address corresponding to a given domain name., , THE DNS DATABASE DNS is based on a hierarchical database containing resource, records (RRs) that include the name, IP address, and other information about hosts., The key features of the database are as follows:, ■, , Variable-depth hierarchy for names: DNS allows essentially unlimited levels, and uses the period (.) as the level delimiter in printed names, as described, earlier.
Page 641 :
640, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, Table 19.6, Type, A, AAAA, CNAME, HINFO, MINFO, MX, NS, PTR, SOA, SRV, TXT, WKS, ■, ■, , Resource Record Types, Description, A host address. This RR type maps the name of a system to its IPv4 address. Some, systems (e.g., routers) have multiple addresses, and there is a separate RR for each., Similar to A type, but for IPv6 addresses., Canonical name. Specifies an alias name for a host and maps this to the canonical, (true) name., Host information. Designates the processor and operating system used by the host., Mailbox or mail list information. Maps a mailbox or mail list name to a host name., Mail exchange. Identifies the system(s) via which mail to the queried domain name, should be relayed., Authoritative name server for this domain., Domain name pointer. Points to another part of the domain name space., Start of a zone of authority (which part of naming hierarchy is implemented). Includes, parameters related to this zone., For a given service provides name of server or servers in domain that provide that service., Arbitrary text. Provides a way to add text comments to the database., Well-known services. May list the application services available at this host., , Distributed database: The database resides in DNS servers scattered throughout the Internet., Distribution controlled by the database: The DNS database is divided into, thousands of separately managed zones, which are managed by separate, administrators. Distribution and update of records is controlled by the database, software., , Using this database, DNS servers provide a name-to-address directory service, for network applications that need to locate specific servers. For example, every, time an email message is sent or a Web page is accessed, there must be a DNS name, lookup to determine the IP address of the email server or Web server., Table 19.6 lists the various types of resource records., DNS OPERATION DNS operation typically includes the following steps (Figure 19.6):, 1. A user program requests an IP address for a domain name., 2. A resolver module in the local host or local ISP queries a local name server in, the same domain as the resolver., 3. The local name server checks to see if the name is in its local database or cache,, and, if so, returns the IP address to the requestor. Otherwise, the name server, queries other available name servers, if necessary going to the root server, as, explained subsequently., 4. When a response is received at the local name server, it stores the name/, address mapping in its local cache and may maintain this entry for the amount, of time specified in the time-to-live field of the retrieved RR., 5. The user program is given the IP address or an error message., , Hiva-Network.Com
Page 642 :
19.6 / DNSSEC, , 641, , Cache, , Foreign, name, server, , User, program, , user, query, user, response, , User, system, , Database, , Internet, query, Name, resolver, , y, , er, , qu, , response, , e, , ns, , po, , s, re, , Cache, Name, server, Database, Cache, , Figure 19.6 DNS Name Resolution, , The distributed DNS database that supports the DNS functionality must be, updated frequently because of the rapid and continued growth of the Internet., Further, the DNS must cope with dynamic assignment of IP addresses, such as is, done for home DSL users by their ISP. Accordingly, dynamic updating functions, for DNS have been defined. In essence, DNS name servers automatically send out, updates to other relevant name servers as conditions warrant., , DNS Security Extensions, DNSSEC provides end-to-end protection through the use of digital signatures that, are created by responding zone administrators and verified by a recipient’s resolver, software. In particular, DNSSEC avoids the need to trust intermediate name servers, and resolvers that cache or route the DNS records originating from the responding, zone administrator before they reach the source of the query. DNSSEC consists of, a set of new resource record types and modifications to the existing DNS protocol,, and is defined in the following documents:, ■, , ■, , RFC 4033, DNS Security Introduction and Requirements: Introduces the, DNS security extensions and describes their capabilities and limitations. The, document also discusses the services that the DNS security extensions do and, do not provide., RFC 4034, Resource Records for the DNS Security Extensions: Defines four, new resource records that provide security for DNS.
Page 643 :
642, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, ■, , RFC 4035, Protocol Modifications for the DNS Security Extensions: Defines, the concept of a signed zone, along with the requirements for serving and, resolving by using DNSSEC. These techniques allow a security-aware resolver, to authenticate both DNS resource records and authoritative DNS error, indications., , DNSSEC OPERATION In essence, DNSSEC is designed to protect DNS clients, from accepting forged or altered DNS resource records. It does this by using digital, signatures to provide:, ■, ■, , Data origin authentication: Ensures that data has originated from the correct, source., Data integrity verification: Ensures that the content of a RR has not been, modified., , The DNS zone administrator digitally signs every Resource Record set, (RRset) in the zone, and publishes this collection of digital signatures, along with, the zone administrator’s public key, in the DNS itself. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third, party or a chain of third parties (as in public key infrastructure [PKI] chaining), but, by starting from a trusted zone (such as the root zone) and establishing the chain of, trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone, is called the trust anchor., RESOURCE RECORDS, records:, ■, ■, ■, ■, , FOR, , DNSSEC RFC 4034 defines four new DNS resource, , DNSKEY: Contains a public key., RRSIG: A resource record digital signature., NSEC: Authenticated denial of existence record., DS: Delegation signer., , An RRSIG is associated with each RRset, where an RRset is the set of, resource records that have the same label, class, and type. When a client requests, data, an RRset is returned, together with the associated digital signature in an, RRSIG record. The client obtains the relevant DNSKEY public key and verifies, the signature for this RRset., DNSSEC depends on establishing the authenticity of the DNS hierarchy leading to the domain name in question, and thus its operation depends on beginning, the use of cryptographic digital signatures in the root zone. The DS resource record, facilitates key signing and authentication between DNS zones to create an authentication chain, or trusted sequence of signed data, from the root of the DNS tree, down to a specific domain name. To secure all DNS lookups, including those for, non-existent domain names and record types, DNSSEC uses the NSEC resource, record to authenticate negative responses to queries. NSEC is used to identify the
Page 644 :
19.7 / DNS-BASED AUTHENTICATION OF NAMED ENTITIES, , 643, , range of DNS names or resource record types that do not exist among the sequence, of domain names in a zone., , 19.7 DNS-BASED AUTHENTICATION OF NAMED ENTITIES, DANE is a protocol to allow X.509 certificates, commonly used for Transport Layer, Security (TLS), to be bound to DNS names using DNSSEC. It is proposed in RFC, 6698 as a way to authenticate TLS client and server entities without a certificate, authority (CA)., The rationale for DANE is the vulnerability of the use of CAs in a global PKI, system. Every browser developer and operating system supplier maintains a list of, CA root certificates as trust anchors. These are called the software’s root certificates and are stored in its root certificate store. The PKIX procedure allows a certificate recipient to trace a certificate back to the root. So long as the root certificate, remains trustworthy, and the authentication concludes successfully, the client can, proceed with the connection., However, if any of the hundreds of CAs operating on the Internet is compromised, the effects can be widespread. The attacker can obtain the CA’s private key,, get issued certificates under a false name, or introduce new bogus root certificates, into a root certificate store. There is no limitation of scope for the global PKI and, a compromise of a single CA damages the integrity of the entire PKI system. In, addition, some CAs have engaged in poor security practices. For example, some, CAs have issued wildcard certificates that allow the holder to issue sub-certificates, for any domain or entity, anywhere in the world., The purpose of DANE is to replace reliance on the security of the CA system, with reliance on the security provided by DNSSEC. Given that the DNS administrator for a domain name is authorized to give identifying information about the, zone, it makes sense to allow that administrator to also make an authoritative binding between the domain name and a certificate that might be used by a host at that, domain name., , TLSA Record, DANE defines a new DNS record type, TLSA, that can be used for a secure method, of authenticating SSL/TLS certificates. The TLSA provides for:, ■, ■, , Specifying constraints on which CA can vouch for a certificate, or which, specific PKIX end-entity certificate is valid., Specifying that a service certificate or a CA can be directly authenticated in, the DNS itself., , The TLSA RR enables certificate issue and delivery to be tied to a given, domain. A server domain owner creates a TLSA resource record that identifies the, certificate and its public key. When a client receives an X.509 certificate in the TLS, negotiation, it looks up the TLSA RR for that domain and matches the TLSA data, against the certificate as part of the client’s certificate validation procedure.
Page 645 :
644, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, Bit:, , 0, , 8, , Certificate usage, , 16, , Selector, , 24, , 31, , Matching type, , Certificate association data, , Figure 19.7 TLSA RR Transmission Format, , Figure 19.7 shows the format of a TLSA RR as it is transmitted to a requesting entity. It contains four fields. The Certificate Usage field defines four different, usage models, to accommodate users who require different forms of authentication., The usage models are:, ■, , ■, , ■, , ■, , PKIX-TA (CA constraint): Specifies which CA should be trusted to authenticate the certificate for the service. This usage model limits which CA can be, used to issue certificates for a given service on a host. The server certificate, chain must pass PKIX validation that terminates with a trusted root certificate, stored in the client., PKIX-EE (service certificate constraint): Defines which specific end entity, service certificate should be trusted for the service. This usage model limits, which end entity certificate can be used by a given service on a host. The server, certificate chain must pass PKIX validation that terminates with a trusted root, certificate stored in the client., DANE-TA (trust anchor assertion): Specifies a domain-operated CA to be, used as a trust anchor. This usage model allows a domain name administrator, to specify a new trust anchor—for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users’ collection, of trust anchors. The server certificate chain is self-issued and does not need to, verify against a trusted root stored in the client., DANE-EE (domain-issued certificate): Specifies a domain-operated CA to, be used as a trust anchor. This certificate usage allows a domain name administrator to issue certificates for a domain without involving a third-party CA., The server certificate chain is self-issued and does not need to verify against a, trusted root stored in the client., , The first two usage models are designed to co-exist with and strengthen, the public CA system. The final two usage models operate without the use of, public CAs., The Selector field indicates whether the full certificate will be matched or just, the value of the public key. The match is made between the certificate presented, in TLS negotiation and the certificate in the TLSA RR. The Matching Type field, indicates how the match of the certificate is made. The options are exact match,, SHA-256 hash match, or SHA-512 hash match. The Certificate Association Data is, the raw certificate data in hex format.
Page 646 :
19.8 / SENDER POLICY FRAMEWORK, , 645, , Use of DANE for SMTP, DANE can be used in conjunction with SMTP over TLS, as provided by STARTTLS,, to more fully secure email delivery. DANE can authenticate the certificate of the, SMTP submission server that the user’s mail client (MUA) communicates with. It, can also authenticate the TLS connections between SMTP servers (MTAs). The, use of DANE with SMTP is documented in an Internet Draft (SMTP Security via, Opportunistic DANE TLS, draft-ietf-dane-smtp-with-dane-19, May 29, 2015)., As discussed in Section 19.1, SMTP can use the STARTTLS extension to, run SMTP over TLS, so that the entire email message plus SMTP envelope are, encrypted. This is done opportunistically, that is, if both sides support STARTTLS., Even when TLS is used to provide confidentiality, it is vulnerable to attack in the, following ways:, ■, ■, , Attackers can strip away the TLS capability advertisement and downgrade the, connection to not use TLS., TLS connections are often unauthenticated (e.g., the use of self-signed certificates as well as mismatched certificates is common)., , DANE can address both these vulnerabilities. A domain can use the presence, of the TLSA RR as an indicator that encryption must be performed, thus preventing malicious downgrade. A domain can authenticate the certificate used in the TLS, connection setup using a DNSSEC-signed TLSA RR., , Use of DNSSEC for S/MIME, DNSSEC can be used in conjunction with S/MIME to more fully secure email, delivery, in a manner similar to the DANE functionality. This use is documented in, an Internet Draft (Using Secure DNS to Associate Certificates with Domain Names, for S/MIME, draft-ietf-dane-smime-09, August 27, 2015), which proposes a new, SMIMEA DNS RR. The purpose of the SMIMEA RR is to associate certificates, with DNS domain names., As discussed in Section 19.4, S/MIME messages often contain certificates, that can assist in authenticating the message sender and can be used in encrypting messages sent in reply. This feature requires that the receiving MUA validate, the certificate associated with the purported sender. SMIMEA RRs can provide a, secure means of doing this validation., In essence, the SMIMEA RR will have the same format and content as the, TLSA RR, with the same functionality. The difference is that it is geared to the, needs of MUAs in dealing with domain names as specified in email addresses in the, message body, rather than domain names specified in the outer SMTP envelope., , 19.8 SENDER POLICY FRAMEWORK, SPF is the standardized way for a sending domain to identify and assert the mail, senders for a given domain. The problem that SPF addresses is the following: With, the current email infrastructure, any host can use any domain name for each of the
Page 647 : 646, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , various identifiers in the mail header, not just the domain name where the host is, located. Two major drawbacks of this freedom are:, ■, , ■, , It is a major obstacle to reducing unsolicited bulk email (UBE), also known as, spam. It makes it difficult for mail handlers to filter out emails on the basis of, known UBE sources., ADMDs (see Section 19.1) are understandably concerned about the ease with, which other entities can make use of their domain names, often with malicious, intent., , RFC 7208 defines the SPF. It provides a protocol by which ADMDs can, authorize hosts to use their domain names in the “MAIL FROM” or “HELO”, identities. Compliant ADMDs publish Sender Policy Framework (SPF) records in, the DNS specifying which hosts are permitted to use their names, and compliant, mail receivers use the published SPF records to test the authorization of sending, Mail Transfer Agents (MTAs) using a given “HELO” or “MAIL FROM” identity, during a mail transaction., SPF works by checking a sender’s IP address against the policy encoded in any, SPF record found at the sending domain. The sending domain is the domain used, in the SMTP connection, not the domain indicated in the message header as displayed in the MUA. This means that SPF checks can be applied before the message, content is received from the sender., Figure 19.8 is an example in which SPF would come into play. Assume that the, sender’s IP address is 192.168.0.1. The message arrives from the MTA with domain, mta.example.net. The sender uses the MAIL FROM tag of
[email protected],, indicating that the message originates in the example.org domain. But the message, header specifies
[email protected]. The receiver uses SPF to query for the, SPF RR that corresponds to example.com to check if the IP address 192.168.0.1 is, , S: 220 foo.com Simple Mail Transfer Service Ready, C: HELO mta.example.net, S: 250 OK, C: MAIL FROM:<
[email protected]>, S: 250 OK, C: RCPT TO:<
[email protected]>, S: 250 OK, C: DATA, S: 354 Start mail input; end with <crlf>.<crlf>, C: To:
[email protected], C: From:
[email protected], C: Date: Today, C: Subject: Meeting Today, . . ., , Figure 19.8, , Example in which SMTP Envelope Header Does, Not Match Message Header
Page 648 :
19.8 / SENDER POLICY FRAMEWORK, , 647, , listed as a valid sender, and then takes appropriate action based on the results of, checking the RR., , SPF on the Sender Side, A sending domain needs to identify all the senders for a given domain and add, that information into the DNS as a separate resource record. Next, the sending, domain encodes the appropriate policy for each sender using the SPF syntax. The, encoding is done in a TXT DNS resource record as a list of mechanisms and modifiers. Mechanisms are used to define an IP address or range of addresses to be, matched, and modifiers indicate the policy for a given match. Table 19.7 lists the, most important mechanisms and modifiers used in SPF., The SPF syntax is fairly complex and can express complex relationships, between senders. For more detail, see RFC 7208., , SPF on the Receiver Side, If SPF is implemented at a receiver, the SPF entity uses the SMTP envelope MAIL, FROM: address domain and the IP address of the sender to query an SPF TXT RR., The SPF checks can be started before the body of the email message is received,, Table 19.7 Common SPF Mechanisms and Modifiers, Tag, , Description, , ip4, , Specifies an IPv4 address or range of addresses that are authorized senders for, a domain., , ip6, , Specifies an IPv6 address or range of addresses that are authorized senders for, a domain., , mx, , Asserts that the listed hosts for the Mail Exchange RRs are also valid senders for, the domain., , include, , Lists another domain where the receiver should look for an SPF RR for further, senders. This can be useful for large organizations with many domains or, sub-domains that have a single set of shared senders. The include mechanism is, recursive, in that the SPF check in the record found is tested in its entirety before, proceeding. It is not simply a concatenation of the checks., , all, , Matches every IP address that has not otherwise been matched., , (a) SPF Mechanisms, Modifier, , Description, , +, , The given mechanism check must pass. This is the default mechanism and does not, need to be explicitly listed., , -, , The given mechanism is not allowed to send email on behalf of the domain., , ∼, , The given mechanism is in transition and if an email is seen from the listed host/IP, address, then it should be accepted but marked for closer inspection., , ?, , The SPF RR explicitly states nothing about the mechanism. In this case, the default, behavior is to accept the email. (This makes it equivalent to = + > unless some sort of, discrete or aggregate message review is conducted.), , (b) SPF Mechanism Modifiers
Page 649 :
648, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, Inbox, , Inbound, mail server, , Sender, , Junk email, , Internet, Authorization, pass/fail, , SPF record, lookup, , Quarantine, Further, policy, checks, Block/delete, , DNS, , Figure 19.9 Sender Policy Framework Operation, , which may result in blocking the transmission of the email content. Alternatively,, the entire message can be absorbed and buffered until all the checks are finished., In either case, checks must be completed before the mail message is sent to the end, user’s inbox., The checking involves the following rules:, 1. If no SPF TXT RR is returned, the default behavior is to accept the message., 2. If the SPF TXT RR has formatting errors, the default behavior is to accept the, message., 3. Otherwise the mechanisms and modifiers in the RR are used to determine, disposition of the email message., Figure 19.9 illustrates SPF operation., , 19.9 DOMAINKEYS IDENTIFIED MAIL, DomainKeys Identified Mail (DKIM) is a specification for cryptographically, signing email messages, permitting a signing domain to claim responsibility for a, message in the mail stream. Message recipients (or agents acting in their behalf), can verify the signature by querying the signer’s domain directly to retrieve the, appropriate public key and thereby can confirm that the message was attested to, by a party in possession of the private key for the signing domain. DKIM is an, Internet Standard (RFC 6376: DomainKeys Identified Mail (DKIM) Signatures)., DKIM has been widely adopted by a range of email providers, including, corporations, government agencies, gmail, Yahoo!, and many Internet Service, Providers (ISPs).
Page 650 :
19.9 / DOMAINKEYS IDENTIFIED MAIL, , 649, , Email Threats, RFC 4686 (Analysis of Threats Motivating DomainKeys Identified Mail) describes, the threats being addressed by DKIM in terms of the characteristics, capabilities,, and location of potential attackers., CHARACTERISTICS RFC 4686 characterizes the range of attackers on a spectrum of, three levels of threat., 1. At the low end are attackers who simply want to send email that a recipient, does not want to receive. The attacker can use one of a number of commercially, available tools that allow the sender to falsify the origin address of messages., This makes it difficult for the receiver to filter spam on the basis of originating, address or domain., 2. At the next level are professional senders of bulk spam mail. These attackers, often operate as commercial enterprises and send messages on behalf of third, parties. They employ more comprehensive tools for attack, including Mail, Transfer Agents (MTAs) and registered domains and networks of compromised computers (zombies), to send messages and (in some cases) to harvest, addresses to which to send., 3. The most sophisticated and financially motivated senders of messages are, those who stand to receive substantial financial benefit, such as from an emailbased fraud scheme. These attackers can be expected to employ all of the, above mechanisms and additionally may attack the Internet infrastructure, itself, including DNS cache-poisoning attacks and IP routing attacks., CAPABILITIES RFC 4686 lists the following as capabilities that an attacker might, have., 1. Submit messages to MTAs and Message Submission Agents (MSAs) at, multiple locations in the Internet., 2. Construct arbitrary Message Header fields, including those claiming to be, mailing lists, resenders, and other mail agents., 3. Sign messages on behalf of domains under their control., 4. Generate substantial numbers of either unsigned or apparently signed, messages that might be used to attempt a denial-of-service attack., 5. Resend messages that may have been previously signed by the domain., 6. Transmit messages using any envelope information desired., 7. Act as an authorized submitter for messages from a compromised computer., 8. Manipulation of IP routing. This could be used to submit messages from, specific IP addresses or difficult-to-trace addresses, or to cause diversion of, messages to a specific domain., 9. Limited influence over portions of DNS using mechanisms such as cache, poisoning. This might be used to influence message routing or to falsify advertisements of DNS-based keys or signing practices., , Hiva-Network.Com
Page 651 :
650, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , 10. Access to significant computing resources, for example, through the conscription of worm-infected “zombie” computers. This could allow the “bad actor” to, perform various types of brute-force attacks., 11. Ability to eavesdrop on existing traffic, perhaps from a wireless network., LOCATION DKIM focuses primarily on attackers located outside of the administrative units of the claimed originator and the recipient. These administrative units, frequently correspond to the protected portions of the network adjacent to the originator and recipient. It is in this area that the trust relationships required for authenticated message submission do not exist and do not scale adequately to be practical., Conversely, within these administrative units, there are other mechanisms (such as, authenticated message submission) that are easier to deploy and more likely to be, used than DKIM. External bad actors are usually attempting to exploit the “any-toany” nature of email that motivates most recipient MTAs to accept messages from, anywhere for delivery to their local domain. They may generate messages without, signatures, with incorrect signatures, or with correct signatures from domains with, little traceability. They may also pose as mailing lists, greeting cards, or other agents, that legitimately send or resend messages on behalf of others., , DKIM Strategy, DKIM is designed to provide an email authentication technique that is transparent, to the end user. In essence, a user’s email message is signed by a private key of the, administrative domain from which the email originates. The signature covers all of, the content of the message and some of the RFC 5322 message headers. At the, receiving end, the MDA can access the corresponding public key via a DNS and, verify the signature, thus authenticating that the message comes from the claimed, administrative domain. Thus, mail that originates from somewhere else but claims, to come from a given domain will not pass the authentication test and can be, rejected. This approach differs from that of S/MIME and PGP, which use the originator’s private key to sign the content of the message. The motivation for DKIM is, based on the following reasoning:2, 1. S/MIME depends on both the sending and receiving users employing S/MIME., For almost all users, the bulk of incoming mail does not use S/MIME, and the, bulk of the mail the user wants to send is to recipients not using S/MIME., 2. S/MIME signs only the message content. Thus, RFC 5322 header information, concerning origin can be compromised., 3. DKIM is not implemented in client programs (MUAs) and is therefore transparent to the user; the user need not take any action., 4. DKIM applies to all mail from cooperating domains., 5. DKIM allows good senders to prove that they did send a particular message, and to prevent forgers from masquerading as good senders., , 2, , The reasoning is expressed in terms of the use of S/MIME. The same argument applies to PGP.
Page 652 :
19.9 / DOMAINKEYS IDENTIFIED MAIL, , MTA, , MTA, , SMTP, , SMTP, , DNS, , DNS Public key query/response, , MDA, , SMTP, , MSA, , Signer, , 651, , Verifier, , POP, IMAP, SMTP, , MUA, MUA, , Mail origination, network, , Mail delivery, network, , DNS = Domain Name System, MDA = Mail Delivery Agent, MSA = Mail Submission Agent, MTA = Message Transfer Agent, MUA = Message User Agent, , Figure 19.10, , Simple Example of DKIM Deployment, , Figure 19.10 is a simple example of the operation of DKIM. We begin with a, message generated by a user and transmitted into the MHS to an MSA that is within, the user’s administrative domain. An email message is generated by an email client, program. The content of the message, plus selected RFC 5322 headers, is signed by, the email provider using the provider’s private key. The signer is associated with a, domain, which could be a corporate local network, an ISP, or a public email facility, such as gmail. The signed message then passes through the Internet via a sequence, of MTAs. At the destination, the MDA retrieves the public key for the incoming, signature and verifies the signature before passing the message on to the destination, email client. The default signing algorithm is RSA with SHA-256. RSA with SHA-1, also may be used., , DKIM Functional Flow, Figure 19.11 provides a more detailed look at the elements of DKIM operation., Basic message processing is divided between a signing Administrative Management, Domain (ADMD) and a verifying ADMD. At its simplest, this is between the originating ADMD and the delivering ADMD, but it can involve other ADMDs in the, handling path., Signing is performed by an authorized module within the signing ADMD, and uses private information from a Key Store. Within the originating ADMD,
Page 653 :
652, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , RFC 5322 message, , Originating or relaying ADMD:, Sign message with SDID, Private, key, store, , Internet, , (paired), Public, key, store, , Relaying or delivering ADMD:, Message signed?, , Remote, sender, practices, , no, , yes, Verify, signature, pass, , fail, , Assessments, Check, signing, practices, , Reputation/, accreditation, information, , Message, filtering, engine, , Local info, on sender, practices, , Figure 19.11 DKIM Functional Flow, , this might be performed by the MUA, MSA, or an MTA. Verifying is performed, by an authorized module within the verifying ADMD. Within a delivering, ADMD, verifying might be performed by an MTA, MDA or MUA. The module verifies the signature or determines whether a particular signature was, required. Verifying the signature uses public information from the Key Store., If the signature passes, reputation information is used to assess the signer and, that information is passed to the message filtering system. If the signature fails, or there is no signature using the author’s domain, information about signing, practices related to the author can be retrieved remotely and/or locally, and that, information is passed to the message filtering system. For example, if the sender, (e.g., gmail) uses DKIM but no DKIM signature is present, then the message, may be considered fraudulent.
Page 654 :
19.9 / DOMAINKEYS IDENTIFIED MAIL, , 653, , The signature is inserted into the RFC 5322 message as an additional header, entry, starting with the keyword Dkim-Signature. You can view examples from your, own incoming mail by using the View Long Headers (or similar wording) option for, an incoming message. Here is an example:, Dkim-Signature:, , v=1; a=rsa-sha256; c=relaxed/relaxed;, d=gmail.com; s=gamma; h=domainkeysignature:mime-version:received:date:, message-id:subject :from:to:content-type:, content-transfer-encoding;, bh=5mZvQDyCRuyLb1Y28K4zgS2MPOemFToDBgvbJ, 7GO90s=;, b=PcUvPSDygb4ya5Dyj1rbZGp/VyRiScuaz7TTG, J5qW5slM+klzv6kcfYdGDHzEVJW+Z, FetuPfF1ETOVhELtwH0zjSccOyPkEiblOf6gILO, bm3DDRm3Ys1/FVrbhVOlA+/jH9Aei, uIIw/5iFnRbSH6qPDVv/beDQqAWQfA/wF7O5k=, , Before a message is signed, a process known as canonicalization is performed, on both the header and body of the RFC 5322 message. Canonicalization is necessary, to deal with the possibility of minor changes in the message made en route, including character encoding, treatment of trailing white space in message lines, and the, “folding” and “unfolding” of header lines. The intent of canonicalization is to make a, minimal transformation of the message (for the purpose of signing; the message itself, is not changed, so the canonicalization must be performed again by the verifier) that, will give it its best chance of producing the same canonical value at the receiving end., DKIM defines two header canonicalization algorithms (“simple” and “relaxed”) and, two for the body (with the same names). The simple algorithm tolerates almost no, modification, while the relaxed algorithm tolerates common modifications., The signature includes a number of fields. Each field begins with a tag consisting of a tag code followed by an equals sign and ends with a semicolon. The fields, include the following:, ■, ■, ■, ■, , ■, , v= DKIM version/, a= Algorithm used to generate the signature; must be either rsa-sha1 or, rsa-sha256, c= Canonicalization method used on the header and the body., d= A domain name used as an identifier to refer to the identity of a responsible, person or organization. In DKIM, this identifier is called the Signing Domain, IDentifier (SDID). In our example, this field indicates that the sender is using, a gmail address., s= In order that different keys may be used in different circumstances for the, same signing domain (allowing expiration of old keys, separate departmental signing, or the like), DKIM defines a selector (a name associated with a, key) that is used by the verifier to retrieve the proper key during signature, verification.
Page 655 :
654, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, ■, , ■, ■, , h= Signed Header fields. A colon-separated list of header field names that, identify the header fields presented to the signing algorithm. Note that in our, example above, the signature covers the domainkey-signature field. This refers, to an older algorithm (since replaced by DKIM) that is still in use., bh= The hash of the canonicalized body part of the message. This provides, additional information for diagnosing signature verification failures., b= The signature data in base64 format; this is the encrypted hash code., , 19.10 DOMAIN-BASED MESSAGE AUTHENTICATION,, REPORTING, AND CONFORMANCE, Domain-Based Message Authentication, Reporting, and Conformance (DMARC), allows email senders to specify policy on how their mail should be handled, the, types of reports that receivers can send back, and the frequency those reports, should be sent. It is defined in RFC 7489 (Domain-based Message Authentication,, Reporting, and Conformance, March 2015)., DMARC works with SPF and DKIM. SPF and DKM enable senders to advise, receivers, via DNS, whether mail purporting to come from the sender is valid, and, whether it should be delivered, flagged, or discarded. However, neither SPF nor, DKIM include a mechanism to tell receivers if SPF or DKIM are in use, nor do they, have feedback mechanism to inform senders of the effectiveness of the anti-spam, techniques. For example, if a message arrives at a receiver without a DKIM signature, DKIM provides no mechanism to allow the receiver to learn if the message is, authentic but was sent from a sender that did not implement DKIM, or if the message is a spoof. DMARC addresses these issues essentially by standardizing how, email receivers perform email authentication using SPF and DKIM mechanisms., , Identifier Alignment, DKIM, SPF, and DMARC authenticate various aspects of an individual message. DKIM authenticates the domain that affixed a signature to the message. SPF, focuses on the SMTP envelope, defined in RFC 5321. It can authenticate either the, domain that appears in the MAIL FROM portion of the SMTP envelope or the, HELO domain, or both. These may be different domains, and they are typically not, visible to the end user., DMARC authentication deals with the From domain in the message header,, as defined in RFC 5322. This field is used as the central identity of the DMARC, mechanism because it is a required message header field and therefore guaranteed, to be present in compliant messages, and most MUAs represent the RFC 5322 From, field as the originator of the message and render some or all of this header field’s, content to end users. The email address in this field is the one used by end users to, identify the source of the message and therefore is a prime target for abuse., DMARC requires that From address match (be aligned with) an Authenticated, Identifier from DKIM or SPF. In the case of DKIM, the match is made between, the DKIM signing domain and the From domain. In the case of SPF, the match is, between the SPF-authenticated domain and the From domain.
Page 656 :
19.10 / DOMAIN-BASED MESSAGE AUTHENTICATION, , 655, , DMARC on the Sender Side, A mail sender that uses DMARC must also use SPF or DKIM, or both. The sender, posts a DMARC policy in the DNS that advises receivers on how to treat messages, that purport to originate from the sender’s domain. The policy is in the form of, a DNS TXT resource record. The sender also needs to establish email addresses, to receive aggregate and forensic reports. As these email addresses are published, unencrypted in the DNS TXT RR, they are easily discovered, leaving the poster, subject to unsolicited bulk email. Thus, the poster of the DNS TXT RR needs to, employ some kind of abuse countermeasures., Similar to SPF and DKIM, the DMARC policy in the TXT RR is encoded, in a series of tag=value pairs separated by semicolons. Table 19.8 describes the, common tags., Once the DMARC RR is posted, messages from the sender are typically, processed as follows:, 1. The domain owner constructs an SPF policy and publishes it in its DNS, database. The domain owner also configures its system for DKIM signing., Finally, the domain owner publishes via the DNS a DMARC message-handling, policy., 2. The author generates a message and hands the message to the domain owner’s, designated mail submission service., 3. The submission service passes relevant details to the DKIM signing module in, order to generate a DKIM signature to be applied to the message., 4. The submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s)., , DMARC on the Receiver Side, A message generated on the sender side may pass through other relays but eventually arrives at a receiver’s transport service. The typical processing order for, DMARC on the receiving side is the following:, 1. The receiver performs standard validation tests, such as checking against IP, blocklists and domain reputation lists, as well as enforcing rate limits from a, particular source., 2. The receiver extracts the RFC 5322 From address from the message. This must, contain a single, valid address or else the mail is refused as an error., 3. The receiver queries for the DMARC DNS record based on the sending domain. If none exists, terminate DMARC processing., 4. The receiver performs DKIM signature checks. If more than one DKIM signature exists in the message, one must verify., 5. The receiver queries for the sending domain’s SPF record and performs SPF, validation checks., 6. The receiver conducts Identifier Alignment checks between the RFC 5321, From and the results of the SPF and DKIM records (if present).
Page 657 : 656, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , Table 19.8, , DMARC Tag and Value Descriptions, , Tag (Name), , v= (Version), p= (Policy), , aspf= (SPF Policy), , adkim= (DKIM, Policy), , fo= (Failure reporting, options), , ruf=, rua=, , ri= (Reporting interval), pct= (Percent), , sp= (Receiver Policy), , Description, Version field that must be present as the first element. By default the value is, always DMARC1., Mandatory policy field. May take values none or quarantine or reject. This, allows for a gradually tightening policy where the sender domain recommends, no specific action on mail that fails DMARC checks (p= none), through treating, failed mail as suspicious (p= quarantine), to rejecting all failed mail, (p= reject), preferably at the SMTP transaction stage., Values are r (default) for relaxed and s for strict SPF domain enforcement. Strict, alignment requires an exact match between the From address domain and the, (passing) SPF check must exactly match the MailFrom address (HELO address)., Relaxed requires that only the From and MailFrom address domains be in, alignment. For example, the MailFrom address domain smtp.example.org and the, From address
[email protected] are in alignment, but not a strict match., Optional. Values are r (default) for relaxed and s for strict DKIM domain, enforcement. Strict alignment requires an exact match between the From, domain in the message header and the DKIM domain presented in the, (d= DKIM), tag. Relaxed requires only that the domain part is in alignment, (as in aspf)., Optional. Ignore if a ruf argument is not also present. Value 0 indicates the, receiver should generate a DMARC failure report if all underlying mechanisms, fail to produce an aligned pass result. Value 1 means generate a DMARC failure, report if any underlying mechanism produces something other than an aligned, pass result. Other possible values are d (generate a DKIM failure report if a, signature failed evaluation), and s (generate an SPF failure report if the message, failed SPF evaluation). These values are not exclusive and may be combined., Optional, but requires the fo argument to be present. Lists a series of URIs, (currently just mailto:<emailaddress>) that list where to send forensic feedback, reports. This is for reports on message-specific failures., Optional list of URIs (like in ruf= , using the mailto: URI) listing where to, send aggregate feedback back to the sender. These reports are sent based on the, interval requested using the ri= option with a default of 86400 seconds if not, listed., Optional with the default value of 86400 seconds. The value listed is the, reporting interval desired by the sender., Optional with the default value of 100. Expresses the percentage of a sender’s, mail that should be subject to the given DMARC policy. This allows senders to, ramp up their policy enforcement gradually and prevent having to commit to a, rigorous policy before getting feedback on their existing policy., Optional with a default value of none. Other values include the same range, of values as the p= argument. This is the policy to be applied to mail from all, identified subdomains of the given DMARC RR., , 7. The results of these steps are passed to the DMARC module along with the, Author’s domain. The DMARC module attempts to retrieve a policy from the, DNS for that domain. If none is found, the DMARC module determines the, organizational domain and repeats the attempt to retrieve a policy from the DNS., 8. If a policy is found, it is combined with the Author’s domain and the SPF and, DKIM results to produce a DMARC policy result (a “pass” or “fail”) and can, optionally cause one of two kinds of reports to be generated.
Page 658 :
19.10 / DOMAIN-BASED MESSAGE AUTHENTICATION,, , 657, , 9. Recipient transport service either delivers the message to the recipient inbox, or takes other local policy action based on the DMARC result., 10. When requested, Recipient transport service collects data from the message, delivery session to be used in providing feedback., Figure 19.12, based on one at DMARC.org, summarizes the sending and, receiving functional flow., , Sender, , Receiver, , Author composes, and sends email, , DKIM, , Standard processing, (including antispam), , Pass, , Retrieve verified, DKIM domains, DKIM, , Apply, DMARC, policy, , SPF, , SPF, , Retrieve, “envelope from”, via SPF, , Sending mail server, attaches DKIM signature, , Fail, , Update periodic, aggregate report, to be sent to sender, , Failure, report, , Standard validation, tests at receiver, (including IP, blocklists,, reputation, rate, limits, etc), , Figure 19.12 DMARC Functional Flow, , Block, , Quarantine
Page 659 :
658, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, , DMARC Reports, DMARC reporting provides the sender’s feedback on their SPF, DKIM, Identifier, Alignment, and message disposition policies, which enable the sender to make, these policies more effective. Two types of reports are sent: aggregate reports and, forensic reports., Aggregate reports are sent by receivers periodically and include aggregate, figures for successful and unsuccessful message authentications, including:, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, , The sender’s DMARC policy for that interval., The message disposition by the receiver (i.e., delivered, quarantined, rejected)., SPF result for a given SPF identifier., DKIM result for a given DKIM identifier., Whether identifiers are in alignment or not., Results classified by sender subdomain., The sending and receiving domain pair., The policy applied, and whether this is different from the policy requested., The number of successful authentications., Totals for all messages received., , This information enables the sender to identify gaps in email infrastructure and policy. SP 800-177 recommends that a sending domain begin by setting, a DMARC policy of p= none, so that the ultimate disposition of a message that, fails some check is determined by the receiver’s local policy. As DMARC aggregate, reports are collected, the sender will have a quantitatively better assessment of the, extent to which the sender’s email is authenticated by outside receivers, and will, be able to set a policy of p =reject, indicating that any message that fails the SPF,, DKIM, and alignment checks really should be rejected. From their own traffic analysis, receivers can develop a determination of whether a sender’s p =reject policy is, sufficiently trustworthy to act on., A forensic report helps the sender refine the component SPF and DKIM, mechanisms as well as alerting the sender that their domain is being used as part, of a phishing/spam campaign. Forensic reports are similar in format to aggregation, reports, with these changes:, ■, , ■, ■, , ■, , Receivers include as much of the message and message header as is reasonable to allow the domain to investigate the failure. Add an Identity-Alignment, field, with DKIM and SPF DMARC-method fields as appropriate., Optionally add a Delivery-Result field., Add DKIM Domain, DKIM Identity, and DKIM selector fields, if the message, was DKIM signed. Optionally also add DKIM Canonical header and body, fields., Add an additional DMARC authentication failure type, for use when some, authentication mechanisms fail to produce aligned identifiers., , Hiva-Network.Com
Page 660 :
19.11 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 659, , 19.11 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, administrative management, domain (ADMD), base64, Cryptographic Message, Syntax (CMS), detached signature, DNS-based Authentication of, Named Entities (DANE), DNS Security Extensions, (DNSSEC), Domain-based Message, Authentication, Reporting,, and Conformance, (DMARC), , Domain Name System (DNS), DomainKeys Identified Mail, (DKIM), electronic mail, Internet Mail Access Protocol, (IMAP), Mail Delivery Agent (MDA), Mail Submission Agent, (MSA), Message Handling Service, (MHS), Message Store, Message Transfer Agents, (MTA), , Message User Agent (MUA), Multipurpose Internet Mail, Extensions (MIME), Post Office Protocol (POP3), Pretty Good Privacy (PGP), Sender Policy Framework, (SPF), session key, Simple Mail Transfer Protocol, (SMTP), STARTTLS, SUBMISSION, S/MIME, trust, , Review Questions, 19.1, 19.2, 19.3, 19.4, 19.5, 19.6, 19.7, 19.8, 19.9, , What types of interoperability issues are involved in internet mail architecture and, how are they handled?, What are the SMTP and MIME standards?, What is the difference between a MIME content type and a MIME transfer encoding?, Briefly explain base64 encoding., Why is base64 conversion useful for an email application?, What is S/MIME?, What are the four principal services provided by S/MIME?, What is the utility of a detached signature?, What is DKIM?, , Problems, 19.1, 19.2, 19.3, 19.4, , 19.5, , The character sequence “<CR><LF>.<CR><LF>” indicates the end of mail data to a, SMTP-server. What happens if the mail data itself contains that character sequence?, What are POP3 and IMAP?, If a lossless compression algorithm, such as ZIP, is used with S/MIME, why is it preferable to generate a signature before applying compression?, Before the deployment of the Domain Name System, a simple text file (HOSTS., TXT) centrally maintained at the SRI Network Information Center was used to, enable mapping between host names and addresses. Each host connected to the, Internet had to have an updated local copy of it to be able to use host names instead, of having to cope directly with their IP addresses. Discuss the main advantages of the, DNS over the old centralized HOSTS.TXT system., For this problem and the next few, consult Appendix P. In Figure P.2, each entry in, the public-key ring contains an Owner Trust field that indicates the degree of trust, associated with this public-key owner. Why is that not enough? That is, if this owner, is trusted and this is supposed to be the owner’s public key, why is that trust not, enough to permit PGP to use this public key?
Page 661 :
660, , CHAPTER 19 / ELECTRONIC MAIL SECURITY, 19.6, 19.7, 19.8, , 19.9, , 19.10, , 19.11, , 19.12, , What is the basic difference between X.509 and PGP in terms of key hierarchies and, key trust?, In PGP, what is the expected number of session keys generated before a previously, created key is produced?, A PGP user may have multiple public keys. So that a recipient knows which public, key is being used by a sender, a key ID, consisting of the least significant 64 bits of the, public key, is sent with the message. What is the probability that a user with N public, keys will have at least one duplicate key ID?, The first 16 bits of the message digest in a PGP signature are translated in the clear., This enables the recipient to determine if the correct public key was used to decrypt, the message digest by comparing this plaintext copy of the first two octets with the, first two octets of the decrypted digest., a. To what extent does this compromise the security of the hash algorithm?, b. To what extent does it in fact perform its intended function, namely, to help determine if the correct RSA key was used to decrypt the digest?, Consider base64 conversion as a form of encryption. In this case, there is no key. But, suppose that an opponent knew only that some form of substitution algorithm was, being used to encrypt English text and did not guess that it was base64. How effective, would this algorithm be against cryptanalysis?, Encode the text “ciphertext” using the following techniques. Assume characters are, stored in 8-bit ASCII with zero parity., a. base64, b. Quoted-printable, Use a 2 * 2 matrix to categorize the properties of the four certificate usage models in, DANE.
Page 662 :
CHAPTER, , IP Security, 20.1 IP Security Overview, Applications of IPsec, Benefits of IPsec, Routing Applications, IPsec Documents, IPsec Services, Transport and Tunnel Modes, 20.2 IP Security Policy, Security Associations, Security Association Database, Security Policy Database, IP Traffic Processing, 20.3 Encapsulating Security Payload, ESP Format, Encryption and Authentication Algorithms, Padding, Anti-Replay Service, Transport and Tunnel Modes, 20.4 Combining Security Associations, Authentication Plus Confidentiality, Basic Combinations of Security Associations, 20.5 Internet Key Exchange, Key Determination Protocol, Header and Payload Formats, 20.6 Cryptographic Suites, 20.7 Key Terms, Review Questions, and Problems, , 661
Page 663 :
662, , CHAPTER 20 / IP SECURITY, , LEARNING OBJECTIVES, After studying this chapter, you should be able to:, ◆, ◆, ◆, ◆, ◆, ◆, ◆, ◆, ◆, , Present an overview of IP security (IPsec)., Explain the difference between transport mode and tunnel mode., Understand the concept of security association., Explain the difference between the security association database and the, security policy database., Summarize the traffic processing functions performed by IPsec for outbound packets and for inbound packets., Present an overview of Encapsulating Security Payload., Discuss the alternatives for combining security associations., Present an overview of Internet Key Exchange., Summarize the alternative cryptographic suites approved for use with IPsec., , There are application-specific security mechanisms for a number of application, areas, including electronic mail (S/MIME, PGP), client/server (Kerberos), Web access (Secure Sockets Layer), and others. However, users have security concerns that, cut across protocol layers. For example, an enterprise can run a secure, private IP, network by disallowing links to untrusted sites, encrypting packets that leave the, premises, and authenticating packets that enter the premises. By implementing security at the IP level, an organization can ensure secure networking not only for, applications that have security mechanisms but also for the many security-ignorant, applications., IP-level security encompasses three functional areas: authentication, confidentiality, and key management. The authentication mechanism assures that a received, packet was, in fact, transmitted by the party identified as the source in the packet, header. In addition, this mechanism assures that the packet has not been altered in, transit. The confidentiality facility enables communicating nodes to encrypt messages, to prevent eavesdropping by third parties. The key management facility is concerned, with the secure exchange of keys., We begin this chapter with an overview of IP security (IPsec) and an introduction to the IPsec architecture. We then look at each of the three functional areas in, detail. Appendix L reviews Internet protocols., , 20.1 IP SECURITY OVERVIEW, In 1994, the Internet Architecture Board (IAB) issued a report titled “Security in, the Internet Architecture” (RFC 1636). The report identified key areas for security, mechanisms. Among these were the need to secure the network infrastructure from
Page 664 :
20.1 / IP SECURITY OVERVIEW, , 663, , unauthorized monitoring and control of network traffic and the need to secure enduser-to-end-user traffic using authentication and encryption mechanisms., To provide security, the IAB included authentication and encryption as necessary security features in the next-generation IP, which has been issued as IPv6., Fortunately, these security capabilities were designed to be usable both with the, current IPv4 and the future IPv6. This means that vendors can begin offering these, features now, and many vendors now do have some IPsec capability in their products. The IPsec specification now exists as a set of Internet standards., , Applications of IPsec, IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:, ■, , ■, , ■, , ■, , Secure branch office connectivity over the Internet: A company can build a, secure virtual private network over the Internet or over a public WAN. This, enables a business to rely heavily on the Internet and reduce its need for private networks, saving costs and network management overhead., Secure remote access over the Internet: An end user whose system is equipped, with IP security protocols can make a local call to an Internet Service Provider, (ISP) and gain secure access to a company network. This reduces the cost of, toll charges for traveling employees and telecommuters., Establishing extranet and intranet connectivity with partners: IPsec can be, used to secure communication with other organizations, ensuring authentication and confidentiality and providing a key exchange mechanism., Enhancing electronic commerce security: Even though some Web and electronic commerce applications have built-in security protocols, the use of IPsec, enhances that security. IPsec guarantees that all traffic designated by the network administrator is both encrypted and authenticated, adding an additional, layer of security to whatever is provided at the application layer., , The principal feature of IPsec that enables it to support these varied applications is that it can encrypt and/or authenticate all traffic at the IP level. Thus, all distributed applications (including remote logon, client/server, email, file transfer, Web, access, and so on) can be secured. Figure 20.1a shows a simplified packet format for, an IPsec option known as tunnel mode, described subsequently. Tunnel mode makes, use of an IPsec function, a combined authentication/encryption function called, Encapsulating Security Payload (ESP), and a key exchange function. For VPNs,, both authentication and encryption are generally desired, because it is important, both to (1) assure that unauthorized users do not penetrate the VPN, and (2) assure, that eavesdroppers on the Internet cannot read messages sent over the VPN., Figure 20.1b is a typical scenario of IPsec usage. An organization maintains, LANs at dispersed locations. Nonsecure IP traffic is conducted on each LAN. For, traffic offsite, through some sort of private or public WAN, IPsec protocols are used., These protocols operate in networking devices, such as a router or firewall, that, connect each LAN to the outside world. The IPsec networking device will typically, encrypt all traffic going into the WAN and decrypt traffic coming from the WAN;, these operations are transparent to workstations and servers on the LAN. Secure
Page 665 :
664, , CHAPTER 20 / IP SECURITY, authenticated, encrypted, New IP ESP, hdr, hdr, , orig IP, hdr, , IP payload, , ESP ESP, trlr auth, , (a) Tunnel-mode format, , Public (Internet), or private, network, , User system, with IPSec, , Networking device, with IPSec, , Ethernet, switch, , Legend:, , IP traffic, protected, by IPSec, , Unprotected, IP traffic, , Virtual tunnel:, protected, by IPSec, , (b) Example configuration, , Figure 20.1 An IPSec VPN Scenario, , transmission is also possible with individual users who dial into the WAN. Such user, workstations must implement the IPsec protocols to provide security., , Benefits of IPsec, Some of the benefits of IPsec:, ■, , When IPsec is implemented in a firewall or router, it provides strong security, that can be applied to all traffic crossing the perimeter. Traffic within a company or workgroup does not incur the overhead of security-related processing.
Page 666 :
20.1 / IP SECURITY OVERVIEW, ■, , ■, , ■, , ■, , 665, , IPsec in a firewall is resistant to bypass if all traffic from the outside must use, IP and the firewall is the only means of entrance from the Internet into the, organization., IPsec is below the transport layer (TCP, UDP) and so is transparent to applications. There is no need to change software on a user or server system when, IPsec is implemented in the firewall or router. Even if IPsec is implemented in, end systems, upper-layer software, including applications, is not affected., IPsec can be transparent to end users. There is no need to train users on security mechanisms, issue keying material on a per-user basis, or revoke keying, material when users leave the organization., IPsec can provide security for individual users if needed. This is useful for offsite workers and for setting up a secure virtual subnetwork within an organization for sensitive applications., , Routing Applications, In addition to supporting end users and protecting premises systems and networks,, IPsec can play a vital role in the routing architecture required for internetworking., [HUIT98] lists the following examples of the use of IPsec. IPsec can assure that, ■, ■, , ■, ■, , A router advertisement (a new router advertises its presence) comes from an, authorized router., A neighbor advertisement (a router seeks to establish or maintain a neighbor, relationship with a router in another routing domain) comes from an authorized router., A redirect message comes from the router to which the initial IP packet was sent., A routing update is not forged., , Without such security measures, an opponent can disrupt communications, or divert some traffic. Routing protocols such as Open Shortest Path First (OSPF), should be run on top of security associations between routers that are defined by, IPsec., , IPsec Documents, IPsec encompasses three functional areas: authentication, confidentiality, and key, management. The totality of the IPsec specification is scattered across dozens of, RFCs and draft IETF documents, making this the most complex and difficult to, grasp of all IETF specifications. The best way to grasp the scope of IPsec is to, consult the latest version of the IPsec document roadmap, which as of this writing is RFC 6071 [IP Security (IPsec) and Internet Key Exchange (IKE) Document, Roadmap, February 2011]. The documents can be categorized into the following, groups., ■, , Architecture: Covers the general concepts, security requirements, definitions,, and mechanisms defining IPsec technology. The current specification is RFC, 4301, Security Architecture for the Internet Protocol.
Page 667 :
666, , CHAPTER 20 / IP SECURITY, ■, , ■, , ■, , ■, , ■, , Authentication Header (AH): AH is an extension header to provide message authentication. The current specification is RFC 4302, IP Authentication, Header. Because message authentication is provided by ESP, the use of, AH is deprecated. It is included in IPsecv3 for backward compatibility, but should not be used in new applications. We do not discuss AH in this, chapter., Encapsulating Security Payload (ESP): ESP consists of an encapsulating header and trailer used to provide encryption or combined encryption/, authentication. The current specification is RFC 4303, IP Encapsulating, Security Payload (ESP)., Internet Key Exchange (IKE): This is a collection of documents describing, the key management schemes for use with IPsec. The main specification is, RFC 7296, Internet Key Exchange (IKEv2) Protocol, but there are a number, of related RFCs., Cryptographic algorithms: This category encompasses a large set of documents that define and describe cryptographic algorithms for encryption, message authentication, pseudorandom functions (PRFs), and cryptographic key, exchange., Other: There are a variety of other IPsec-related RFCs, including those dealing with security policy and management information base (MIB) content., , IPsec Services, IPsec provides security services at the IP layer by enabling a system to select, required security protocols, determine the algorithm(s) to use for the service(s),, and put in place any cryptographic keys required to provide the requested services., Two protocols are used to provide security: an authentication protocol designated, by the header of the protocol, Authentication Header (AH); and a combined, encryption/authentication protocol designated by the format of the packet for, that protocol, Encapsulating Security Payload (ESP). RFC 4301 lists the following, services:, ■, ■, ■, ■, ■, ■, , Access control, Connectionless integrity, Data origin authentication, Rejection of replayed packets (a form of partial sequence integrity), Confidentiality (encryption), Limited traffic flow confidentiality, , Transport and Tunnel Modes, Both AH and ESP support two modes of use: transport and tunnel mode. The operation of these two modes is best understood in the context of a description of ESP,, which is covered in Section 20.3. Here we provide a brief overview.
Page 668 :
20.1 / IP SECURITY OVERVIEW, , 667, , TRANSPORT MODE Transport mode provides protection primarily for upper-layer, protocols. That is, transport mode protection extends to the payload of an IP, packet.1 Examples include a TCP or UDP segment or an ICMP packet, all of which, operate directly above IP in a host protocol stack. Typically, transport mode is used, for end-to-end communication between two hosts (e.g., a client and a server, or two, workstations). When a host runs AH or ESP over IPv4, the payload is the data that, normally follow the IP header. For IPv6, the payload is the data that normally follow both the IP header and any IPv6 extensions headers that are present, with the, possible exception of the destination options header, which may be included in the, protection., ESP in transport mode encrypts and optionally authenticates the IP payload, but not the IP header. AH in transport mode authenticates the IP payload and, selected portions of the IP header., TUNNEL MODE Tunnel mode provides protection to the entire IP packet. To achieve, this, after the AH or ESP fields are added to the IP packet, the entire packet plus, security fields is treated as the payload of new outer IP packet with a new outer, IP header. The entire original, inner, packet travels through a tunnel from one, point of an IP network to another; no routers along the way are able to examine, the inner IP header. Because the original packet is encapsulated, the new, larger, packet may have totally different source and destination addresses, adding to the, security. Tunnel mode is used when one or both ends of a security association (SA), are a security gateway, such as a firewall or router that implements IPsec. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure, communications without implementing IPsec. The unprotected packets generated, by such hosts are tunneled through external networks by tunnel mode SAs set up, by the IPsec software in the firewall or secure router at the boundary of the local, network., Here is an example of how tunnel mode IPsec operates. Host A on a network, generates an IP packet with the destination address of host B on another network., This packet is routed from the originating host to a firewall or secure router at the, boundary of A’s network. The firewall filters all outgoing packets to determine the, need for IPsec processing. If this packet from A to B requires IPsec, the firewall, performs IPsec processing and encapsulates the packet with an outer IP header., The source IP address of this outer IP packet is this firewall, and the destination, address may be a firewall that forms the boundary to B’s local network. This packet, is now routed to B’s firewall, with intermediate routers examining only the outer IP, header. At B’s firewall, the outer IP header is stripped off, and the inner packet is, delivered to B., ESP in tunnel mode encrypts and optionally authenticates the entire inner IP, packet, including the inner IP header. AH in tunnel mode authenticates the entire, inner IP packet and selected portions of the outer IP header., Table 20.1 summarizes transport and tunnel mode functionality., 1, , In this chapter, the term IP packet refers to either an IPv4 datagram or an IPv6 packet., , Hiva-Network.Com
Page 669 :
668, , CHAPTER 20 / IP SECURITY, , Table 20.1 Tunnel Mode and Transport Mode Functionality, Transport Mode SA, , Tunnel Mode SA, , AH, , Authenticates IP payload and selected, portions of IP header and IPv6, extension headers., , Authenticates entire inner IP packet (inner, header plus IP payload) plus selected portions, of outer IP header and outer IPv6 extension, headers., , ESP, , Encrypts IP payload and any IPv6, extension headers following the ESP, header., , Encrypts entire inner IP packet., , ESP with, Authentication, , Encrypts IP payload and any IPv6, extension headers following the ESP, header. Authenticates IP payload but, not IP header., , Encrypts entire inner IP packet. Authenticates, inner IP packet., , 20.2 IP SECURITY POLICY, Fundamental to the operation of IPsec is the concept of a security policy applied, to each IP packet that transits from a source to a destination. IPsec policy is, determined primarily by the interaction of two databases, the security association, database (SAD) and the security policy database (SPD). This section provides an, overview of these two databases and then summarizes their use during IPsec operation. Figure 20.2 illustrates the relevant relationships., , Security Associations, A key concept that appears in both the authentication and confidentiality mechanisms for IP is the security association (SA). An association is a one-way logical, connection between a sender and a receiver that affords security services to the traffic carried on it. If a peer relationship is needed for two-way secure exchange, then, two security associations are required., A security association is uniquely identified by three parameters., ■, , ■, , ■, , Security Parameters Index (SPI): A 32-bit unsigned integer assigned to this, SA and having local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received, packet will be processed., IP Destination Address: This is the address of the destination endpoint of the, SA, which may be an end-user system or a network system such as a firewall, or router., Security Protocol Identifier: This field from the outer IP header indicates, whether the association is an AH or ESP security association., , Hence, in any IP packet, the security association is uniquely identified by the, Destination Address in the IPv4 or IPv6 header and the SPI in the enclosed extension header (AH or ESP).
Page 670 :
20.2 / IP SECURITY POLICY, , 669, , Key exchange, , IKEv2, , IKEv2, IKE SA, , SPD, , SPD, , Security, policy, database, , IPsecv3, , SAD, , Security, association, database, , IPsec SA Pair, , ESP protects data, , Security, policy, database, , IPsecv3, , Security, association, database, , SAD, , Figure 20.2 IPsec Architecture, , Security Association Database, In each IPsec implementation, there is a nominal2 Security Association Database, that defines the parameters associated with each SA. A security association is normally defined by the following parameters in an SAD entry., ■, , ■, , ■, , ■, ■, ■, , ■, , 2, , Security Parameter Index: A 32-bit value selected by the receiving end of an, SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI, is used to construct the packet’s AH or ESP header. In an SAD entry for an, inbound SA, the SPI is used to map traffic to the appropriate SA., Sequence Number Counter: A 32-bit value used to generate the Sequence, Number field in AH or ESP headers, described in Section 20.3 (required for all, implementations)., Sequence Counter Overflow: A flag indicating whether overflow of the, Sequence Number Counter should generate an auditable event and prevent, further transmission of packets on this SA (required for all implementations)., Anti-Replay Window: Used to determine whether an inbound AH or ESP, packet is a replay, described in Section 20.3 (required for all implementations)., AH Information: Authentication algorithm, keys, key lifetimes, and related, parameters being used with AH (required for AH implementations)., ESP Information: Encryption and authentication algorithm, keys, initialization, values, key lifetimes, and related parameters being used with ESP (required, for ESP implementations)., Lifetime of this Security Association: A time interval or byte count after, which an SA must be replaced with a new SA (and new SPI) or terminated,, plus an indication of which of these actions should occur (required for all, implementations)., , Nominal in the sense that the functionality provided by a Security Association Database must be present, in any IPsec implementation, but the way in which that functionality is provided is up to the implementer.
Page 671 :
670, , CHAPTER 20 / IP SECURITY, ■, ■, , IPsec Protocol Mode: Tunnel, transport, or wildcard., Path MTU: Any observed path maximum transmission unit (maximum size of, a packet that can be transmitted without fragmentation) and aging variables, (required for all implementations)., , The key management mechanism that is used to distribute keys is coupled to, the authentication and privacy mechanisms only by way of the Security Parameters, Index (SPI). Hence, authentication and privacy have been specified independent of, any specific key management mechanism., IPsec provides the user with considerable flexibility in the way in which IPsec, services are applied to IP traffic. As we will see later, SAs can be combined in a, number of ways to yield the desired user configuration. Furthermore, IPsec provides a high degree of granularity in discriminating between traffic that is afforded, IPsec protection and traffic that is allowed to bypass IPsec, as in the former case, relating IP traffic to specific SAs., , Security Policy Database, The means by which IP traffic is related to specific SAs (or no SA in the case of traffic, allowed to bypass IPsec) is the nominal Security Policy Database (SPD). In its simplest, form, an SPD contains entries, each of which defines a subset of IP traffic and points, to an SA for that traffic. In more complex environments, there may be multiple entries, that potentially relate to a single SA or multiple SAs associated with a single SPD, entry. The reader is referred to the relevant IPsec documents for a full discussion., Each SPD entry is defined by a set of IP and upper-layer protocol field values,, called selectors. In effect, these selectors are used to filter outgoing traffic in order, to map it into a particular SA. Outbound processing obeys the following general, sequence for each IP packet., 1. Compare the values of the appropriate fields in the packet (the selector fields), against the SPD to find a matching SPD entry, which will point to zero or more SAs., 2. Determine the SA if any for this packet and its associated SPI., 3. Do the required IPsec processing (i.e., AH or ESP processing)., The following selectors determine an SPD entry:, ■, , Remote IP Address: This may be a single IP address, an enumerated list or, range of addresses, or a wildcard (mask) address. The latter two are required to, support more than one destination system sharing the same SA (e.g., behind, a firewall)., , ■, , Local IP Address: This may be a single IP address, an enumerated list or range, of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a firewall)., Next Layer Protocol: The IP protocol header (IPv4, IPv6, or IPv6 Extension), includes a field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension), that designates the protocol operating over IP. This is an individual protocol, number, ANY, or for IPv6 only, OPAQUE. If AH or ESP is used, then this IP, protocol header immediately precedes the AH or ESP header in the packet., , ■
Page 672 :
20.2 / IP SECURITY POLICY, Table 20.2, , 671, , Host SPD Example, , Protocol, , Local IP, , Port, , Remote IP, , Port, , Action, , Comment, , UDP, , 1.2.3.101, , 500, , *, , 500, , BYPASS, , IKE, , ICMP, , 1.2.3.101, , *, , *, , *, , BYPASS, , Error messages, , *, , 1.2.3.101, , *, , 1.2.3.0/24, , *, , PROTECT: ESP, intransport-mode, , Encrypt intranet traffic, , TCP, , 1.2.3.101, , *, , 1.2.4.10, , 80, , PROTECT: ESP, intransport-mode, , Encrypt to server, , TCP, , 1.2.3.101, , *, , 1.2.4.10, , 443, , BYPASS, , TLS: avoid double encryption, , *, , 1.2.3.101, , *, , 1.2.4.0/24, , *, , DISCARD, , Others in DMZ, , *, , 1.2.3.101, , *, , *, , *, , BYPASS, , Internet, , ■, , ■, , Name: A user identifier from the operating system. This is not a field in the IP, or upper-layer headers but is available if IPsec is running on the same operating system as the user., Local and Remote Ports: These may be individual TCP or UDP port values, an, enumerated list of ports, or a wildcard port., , Table 20.2 provides an example of an SPD on a host system (as opposed to, a network system such as a firewall or router). This table reflects the following, configuration: A local network configuration consists of two networks. The basic, corporate network configuration has the IP network number 1.2.3.0/24. The local, configuration also includes a secure LAN, often known as a DMZ, that is identified, as 1.2.4.0/24. The DMZ is protected from both the outside world and the rest of the, corporate LAN by firewalls. The host in this example has the IP address 1.2.3.10,, and it is authorized to connect to the server 1.2.4.10 in the DMZ., The entries in the SPD should be self-explanatory. For example, UDP port, 500 is the designated port for IKE. Any traffic from the local host to a remote host, for purposes of an IKE exchange bypasses the IPsec processing., , IP Traffic Processing, IPsec is executed on a packet-by-packet basis. When IPsec is implemented, each, outbound IP packet is processed by the IPsec logic before transmission, and each, inbound packet is processed by the IPsec logic after reception and before passing, the packet contents on to the next higher layer (e.g., TCP or UDP). We look at the, logic of these two situations in turn., OUTBOUND PACKETS Figure 20.3 highlights the main elements of IPsec processing, for outbound traffic. A block of data from a higher layer, such as TCP, is passed, down to the IP layer and an IP packet is formed, consisting of an IP header and an, IP body. Then the following steps occur:, 1. IPsec searches the SPD for a match to this packet., 2. If no match is found, then the packet is discarded and an error message is generated.
Page 673 :
672, , CHAPTER 20 / IP SECURITY, Outbound IP packet, (e.g., from TCP or UDP), , No match, found, , Search, security policy, database, Match found, , Discard DISCARD Determine, policy, packet, , PROTECT, , BYPASS, Match, found, , No match, Search, found, security association, database, , Process, (AH/ESP), , Internet, key, exchange, , Forward, packet via, IP, , Figure 20.3, , Processing Model for Outbound Packets, , 3. If a match is found, further processing is determined by the first matching, entry in the SPD. If the policy for this packet is DISCARD, then the packet is, discarded. If the policy is BYPASS, then there is no further IPsec processing;, the packet is forwarded to the network for transmission., 4. If the policy is PROTECT, then a search is made of the SAD for a matching, entry. If no entry is found, then IKE is invoked to create an SA with the appropriate keys and an entry is made in the SA., 5. The matching entry in the SAD determines the processing for this packet., Either encryption, authentication, or both can be performed, and either transport or tunnel mode can be used. The packet is then forwarded to the network, for transmission., INBOUND PACKETS Figure 20.4 highlights the main elements of IPsec processing for, inbound traffic. An incoming IP packet triggers the IPsec processing. The following, steps occur:, 1. IPsec determines whether this is an unsecured IP packet or one that has ESP, or AH headers/trailers, by examining the IP Protocol field (IPv4) or Next, Header field (IPv6).
Page 674 :
20.3 / ENCAPSULATING SECURITY PAYLOAD, , 673, , Deliver packet, to higher layer, (e.g., TCP, UDP), , Process, (AH/ESP), , BYPASS, Search, security policy, database, , IP, , Not, BYPASS, , Match, found, No match, found, Search, Discard, security association, packet, database, , Packet, type, , IPsec, , Inbound IP packet, (from Internet), , Figure 20.4, , Processing Model for Inbound Packets, , 2. If the packet is unsecured, IPsec searches the SPD for a match to this packet., If the first matching entry has a policy of BYPASS, the IP header is processed, and stripped off and the packet body is delivered to the next higher layer, such, as TCP. If the first matching entry has a policy of PROTECT or DISCARD, or, if there is no matching entry, the packet is discarded., 3. For a secured packet, IPsec searches the SAD. If no match is found, the packet, is discarded. Otherwise, IPsec applies the appropriate ESP or AH processing., Then, the IP header is processed and stripped off and the packet body is delivered to the next higher layer, such as TCP., , 20.3 ENCAPSULATING SECURITY PAYLOAD, ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options, selected at the time of Security Association (SA) establishment and on the location, of the implementation in a network topology., ESP can work with a variety of encryption and authentication algorithms, including authenticated encryption algorithms such as GCM.
Page 675 :
CHAPTER 20 / IP SECURITY, 32 bits, , ICV coverage, , Encrypted, , Security parameters index (SPI), Sequence number, , Payload data (variable), , Padding (0–255 bytes), Pad length, , Next header, , Integrity check value - ICV (variable), , (a) Top-level format of an ESP Packet, , Payload, , ICV coverage, , Security parameters index (SPI), Sequence number, Initialization value - IV (optional), , Encrypted, , 674, , Rest of payload data (variable), , TFC padding (optional, variable), Padding (0–255 bytes), Pad length, , Next header, , Integrity check value - ICV (variable), , (b) Substructure of payload data, Figure 20.5, , ESP Packet Format, , ESP Format, Figure 20.5a shows the top-level format of an ESP packet. It contains the following fields., ■, ■, ■, ■, ■, ■, , ■, , Security Parameters Index (32 bits): Identifies a security association., Sequence Number (32 bits): A monotonically increasing counter value; this, provides an anti-replay function, as discussed for AH., Payload Data (variable): This is a transport-level segment (transport mode) or, IP packet (tunnel mode) that is protected by encryption., Padding (0–255 bytes): The purpose of this field is discussed later., Pad Length (8 bits): Indicates the number of pad bytes immediately preceding, this field., Next Header (8 bits): Identifies the type of data contained in the payload data, field by identifying the first header in that payload (e.g., an extension header, in IPv6, or an upper-layer protocol such as TCP)., Integrity Check Value (variable): A variable-length field (must be an integral, number of 32-bit words) that contains the Integrity Check Value computed, over the ESP packet minus the Authentication Data field.
Page 676 :
20.3 / ENCAPSULATING SECURITY PAYLOAD, , 675, , When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity, check. For combined mode algorithms, the ICV that would normally appear at the, end of the ESP packet (when integrity is selected) may be omitted. When the ICV, is omitted and integrity is selected, it is the responsibility of the combined mode, algorithm to encode within the Payload Data an ICV-equivalent means of verifying, the integrity of the packet., Two additional fields may be present in the payload (Figure 20.5b)., An initialization value (IV), or nonce, is present if this is required by the encryption, or authenticated encryption algorithm used for ESP. If tunnel mode is being used,, then the IPsec implementation may add traffic flow confidentiality (TFC) padding, after the Payload Data and before the Padding field, as explained subsequently., , Encryption and Authentication Algorithms, The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by, the ESP service. If the algorithm used to encrypt the payload requires cryptographic, synchronization data, such as an initialization vector (IV), then these data may be, carried explicitly at the beginning of the Payload Data field. If included, an IV is, usually not encrypted, although it is often referred to as being part of the ciphertext., The ICV field is optional. It is present only if the integrity service is selected, and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The ICV is computed after the encryption is performed., This order of processing facilitates rapid detection and rejection of replayed or, bogus packets by the receiver prior to decrypting the packet, hence potentially reducing the impact of denial of service (DoS) attacks. It also allows for the possibility, of parallel processing of packets at the receiver that is decryption can take place in, parallel with integrity checking. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV., , Padding, The Padding field serves several purposes:, ■, , ■, , ■, , If an encryption algorithm requires the plaintext to be a multiple of some, number of bytes (e.g., the multiple of a single block for a block cipher), the, Padding field is used to expand the plaintext (consisting of the Payload Data,, Padding, Pad Length, and Next Header fields) to the required length., The ESP format requires that the Pad Length and Next Header fields be right, aligned within a 32-bit word. Equivalently, the ciphertext must be an integer, multiple of 32 bits. The Padding field is used to assure this alignment., Additional padding may be added to provide partial traffic-flow confidentiality by concealing the actual length of the payload., , Anti-Replay Service, A replay attack is one in which an attacker obtains a copy of an authenticated, packet and later transmits it to the intended destination. The receipt of duplicate,, authenticated IP packets may disrupt service in some way or may have some other
Page 677 :
676, , CHAPTER 20 / IP SECURITY, , undesired consequence. The Sequence Number field is designed to thwart such attacks. First, we discuss sequence number generation by the sender, and then we, look at how it is processed by the recipient., When a new SA is established, the sender initializes a sequence number, counter to 0. Each time that a packet is sent on this SA, the sender increments the, counter and places the value in the Sequence Number field. Thus, the first value to, be used is 1. If anti-replay is enabled (the default), the sender must not allow the, sequence number to cycle past 232 - 1 back to zero. Otherwise, there would be multiple valid packets with the same sequence number. If the limit of 232 - 1 is reached,, the sender should terminate this SA and negotiate a new SA with a new key., Because IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered in order and does not guarantee that all packets, will be delivered. Therefore, the IPsec authentication document dictates that the, receiver should implement a window of size W, with a default of W = 64. The right, edge of the window represents the highest sequence number, N, so far received for a, valid packet. For any packet with a sequence number in the range from N - W + 1, to N that has been correctly received (i.e., properly authenticated), the corresponding slot in the window is marked (Figure 20.6). Inbound processing proceeds as follows when a packet is received:, 1. If the received packet falls within the window and is new, the MAC is checked., If the packet is authenticated, the corresponding slot in the window is marked., 2. If the received packet is to the right of the window and is new, the MAC is, checked. If the packet is authenticated, the window is advanced so that this, sequence number is the right edge of the window, and the corresponding slot, in the window is marked., 3. If the received packet is to the left of the window or if authentication fails, the, packet is discarded; this is an auditable event., , Transport and Tunnel Modes, Figure 20.7 shows two ways in which the IPsec ESP service can be used. In the upper, part of the figure, encryption (and optionally authentication) is provided directly between two hosts. Figure 20.7b shows how tunnel mode operation can be used to set up, Advance window if, valid packet to the, right is received, Fixed window size W, , , N–W, Marked if valid, packet received, , Figure 20.6 Anti-replay Mechanism, , Hiva-Network.Com, , N, , N+1, Unmarked if valid, packet not yet received
Page 678 :
20.3 / ENCAPSULATING SECURITY PAYLOAD, , 677, , Encrypted, TCP Session, External, Network, , Internal, Network, (a) Transport-level security, , Corporate, network, Encrypted tunnels, carrying IP traffic, , Corporate, network, , Corporate, network, , Internet, , Corporate, network, , (b) A virtual private network via tunnel mode, , Figure 20.7 Transport-Mode versus Tunnel-Mode Encryptionx, , a virtual private network. In this example, an organization has four private networks, interconnected across the Internet. Hosts on the internal networks use the Internet, for transport of data but do not interact with other Internet-based hosts. By terminating the tunnels at the security gateway to each internal network, the configuration allows the hosts to avoid implementing the security capability. The former technique is, supported by a transport mode SA, while the latter technique uses a tunnel mode SA., In this section, we look at the scope of ESP for the two modes. The considerations are somewhat different for IPv4 and IPv6. We use the packet formats of, Figure 20.8a as a starting point., TRANSPORT MODE ESP Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment), as shown in Figure 20.8b., For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to the transport-layer header (e.g., TCP, UDP, ICMP), and an ESP, trailer (Padding, Pad Length, and Next Header fields) is placed after the IP packet., If authentication is selected, the ESP Authentication Data field is added after the, ESP trailer. The entire transport-level segment plus the ESP trailer are encrypted., Authentication covers all of the ciphertext plus the ESP header., In the context of IPv6, ESP is viewed as an end-to-end payload; that is, it is, not examined or processed by intermediate routers. Therefore, the ESP header appears after the IPv6 base header and the hop-by-hop, routing, and fragment extension headers. The destination options extension header could appear before or after, the ESP header, depending on the semantics desired. For IPv6, encryption covers
Page 679 :
678, , CHAPTER 20 / IP SECURITY, Orig IP, hdr, , TCP, , Data, , Extension headers, (if present), , TCP, , Data, , IPv4, , IPv6, , Orig IP, hdr, , (a) Before Applying ESP, authenticated, encrypted, IPv4, , Orig IP, hdr, , ESP, hdr, , TCP, , Data, , ESP ESP, trlr auth, , authenticated, encrypted, Orig IP, hdr, , IPv6, , Hop-by-hop, dest,, routing, fragment, , ESP Dest, hdr, , TCP, , Data, , ESP ESP, trlr auth, , Data, , ESP ESP, trlr auth, , Data, , ESP ESP, trlr auth, , (b) Transport Mode, authenticated, encrypted, IPv4, , New IP ESP Orig IP, hdr, hdr, hdr, , TCP, , authenticated, encrypted, IPv6, , New IP, hdr, , Ext, headers, , ESP Orig IP, hdr, hdr, , Ext, headers, , TCP, , (c) Tunnel Mode, , Figure 20.8, , Scope of ESP Encryption and Authentication, , the entire transport-level segment plus the ESP trailer plus the destination options, extension header if it occurs after the ESP header. Again, authentication covers the, ciphertext plus the ESP header., Transport mode operation may be summarized as follows., 1. At the source, the block of data consisting of the ESP trailer plus the entire, transport-layer segment is encrypted and the plaintext of this block is replaced
Page 680 :
20.3 / ENCAPSULATING SECURITY PAYLOAD, , 679, , with its ciphertext to form the IP packet for transmission. Authentication is, added if this option is selected., 2. The packet is then routed to the destination. Each intermediate router needs, to examine and process the IP header plus any plaintext IP extension headers, but does not need to examine the ciphertext., 3. The destination node examines and processes the IP header plus any plaintext, IP extension headers. Then, on the basis of the SPI in the ESP header, the, destination node decrypts the remainder of the packet to recover the plaintext, transport-layer segment., Transport mode operation provides confidentiality for any application that, uses it, thus avoiding the need to implement confidentiality in every individual application. One drawback to this mode is that it is possible to do traffic analysis on, the transmitted packets., TUNNEL MODE ESP Tunnel mode ESP is used to encrypt an entire IP packet (Figure, 20.8c). For this mode, the ESP header is prefixed to the packet and then the packet, plus the ESP trailer is encrypted. This method can be used to counter traffic analysis., Because the IP header contains the destination address and possibly source, routing directives and hop-by-hop option information, it is not possible simply to, transmit the encrypted IP packet prefixed by the ESP header. Intermediate routers, would be unable to process such a packet. Therefore, it is necessary to encapsulate, the entire block (ESP header plus ciphertext plus Authentication Data, if present), with a new IP header that will contain sufficient information for routing but not for, traffic analysis., Whereas the transport mode is suitable for protecting connections between, hosts that support the ESP feature, the tunnel mode is useful in a configuration that, includes a firewall or other sort of security gateway that protects a trusted network, from external networks. In this latter case, encryption occurs only between an external host and the security gateway or between two security gateways. This relieves, hosts on the internal network of the processing burden of encryption and simplifies, the key distribution task by reducing the number of needed keys. Further, it thwarts, traffic analysis based on ultimate destination., Consider a case in which an external host wishes to communicate with a host, on an internal network protected by a firewall, and in which ESP is implemented, in the external host and the firewalls. The following steps occur for transfer of a, transport-layer segment from the external host to the internal host., 1. The source prepares an inner IP packet with a destination address of the target, internal host. This packet is prefixed by an ESP header; then the packet and, ESP trailer are encrypted and Authentication Data may be added. The resulting block is encapsulated with a new IP header (base header plus optional extensions such as routing and hop-by-hop options for IPv6) whose destination, address is the firewall; this forms the outer IP packet., 2. The outer packet is routed to the destination firewall. Each intermediate, router needs to examine and process the outer IP header plus any outer IP, extension headers but does not need to examine the ciphertext.
Page 682 :
20.4 / COMBINING SECURITY ASSOCIATIONS, , 681, , 20.4 COMBINING SECURITY ASSOCIATIONS, An individual SA can implement either the AH or ESP protocol but not both., Sometimes a particular traffic flow will call for the services provided by both AH, and ESP. Further, a particular traffic flow may require IPsec services between hosts, and, for that same flow, separate services between security gateways, such as firewalls. In all of these cases, multiple SAs must be employed for the same traffic flow, to achieve the desired IPsec services. The term security association bundle refers to, a sequence of SAs through which traffic must be processed to provide a desired set, of IPsec services. The SAs in a bundle may terminate at different endpoints or at, the same endpoints., Security associations may be combined into bundles in two ways:, ■, , ■, , Transport adjacency: Refers to applying more than one security protocol to, the same IP packet without invoking tunneling. This approach to combining, AH and ESP allows for only one level of combination; further nesting yields, no added benefit since the processing is performed at one IPsec instance: the, (ultimate) destination., Iterated tunneling: Refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels, of nesting, since each tunnel can originate or terminate at a different IPsec site, along the path., , The two approaches can be combined, for example, by having a transport SA between hosts travel part of the way through a tunnel SA between security gateways., One interesting issue that arises when considering SA bundles is the order in, which authentication and encryption may be applied between a given pair of endpoints and the ways of doing so. We examine that issue next. Then we look at combinations of SAs that involve at least one tunnel., , Authentication Plus Confidentiality, Encryption and authentication can be combined in order to transmit an IP packet, that has both confidentiality and authentication between hosts. We look at several, approaches., ESP WITH AUTHENTICATION OPTION This approach is illustrated in Figure 20.8., In this approach, the user first applies ESP to the data to be protected and then, appends the authentication data field. There are actually two subcases:, ■, ■, , Transport mode ESP: Authentication and encryption apply to the IP payload, delivered to the host, but the IP header is not protected., Tunnel mode ESP: Authentication applies to the entire IP packet delivered, to the outer IP destination address (e.g., a firewall), and authentication is performed at that destination. The entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP destination., , For both cases, authentication applies to the ciphertext rather than the plaintext.
Page 683 :
682, , CHAPTER 20 / IP SECURITY, , TRANSPORT ADJACENCY Another way to apply authentication after encryption is to, use two bundled transport SAs, with the inner being an ESP SA and the outer being, an AH SA. In this case, ESP is used without its authentication option. Because the, inner SA is a transport SA, encryption is applied to the IP payload. The resulting, packet consists of an IP header (and possibly IPv6 header extensions) followed by, an ESP. AH is then applied in transport mode, so that authentication covers the, ESP plus the original IP header (and extensions) except for mutable fields. The, advantage of this approach over simply using a single ESP SA with the ESP authentication option is that the authentication covers more fields, including the source, and destination IP addresses. The disadvantage is the overhead of two SAs versus, one SA., TRANSPORT-TUNNEL BUNDLE The use of authentication prior to encryption might, be preferable for several reasons. First, because the authentication data are protected by encryption, it is impossible for anyone to intercept the message and alter, the authentication data without detection. Second, it may be desirable to store the, authentication information with the message at the destination for later reference., It is more convenient to do this if the authentication information applies to the unencrypted message; otherwise the message would have to be reencrypted to verify, the authentication information., One approach to applying authentication before encryption between two hosts, is to use a bundle consisting of an inner AH transport SA and an outer ESP tunnel, SA. In this case, authentication is applied to the IP payload plus the IP header (and, extensions) except for mutable fields. The resulting IP packet is then processed in, tunnel mode by ESP; the result is that the entire, authenticated inner packet is encrypted and a new outer IP header (and extensions) is added., , Basic Combinations of Security Associations, The IPsec Architecture document lists four examples of combinations of SAs that, must be supported by compliant IPsec hosts (e.g., workstation, server) or security, gateways (e.g., firewall, router). These are illustrated in Figure 20.10. The lower, part of each case in the figure represents the physical connectivity of the elements;, the upper part represents logical connectivity via one or more nested SAs. Each SA, can be either AH or ESP. For host-to-host SAs, the mode may be either transport, or tunnel; otherwise it must be tunnel mode., Case 1. All security is provided between end systems that implement IPsec., For any two end systems to communicate via an SA, they must share the appropriate secret keys. Among the possible combinations are, a., b., c., d., , AH in transport mode, ESP in transport mode, ESP followed by AH in transport mode (an ESP SA inside an AH SA), Any one of a, b, or c inside an AH or ESP in tunnel mode, , We have already discussed how these various combinations can be used to, support authentication, encryption, authentication before encryption, and authentication after encryption.
Page 684 :
Local, Intranet, , Local, Intranet, , Figure 20.10, , (b) Case 2, , Internet, , Security, Gateway*, , Tunnel SA, , (a) Case 1, , Internet, , Local, Intranet, , Security, Gateway*, , Local, Intranet, , Router, , Host, , Host*, , Basic Combinations of Security Associations, , * = implements IPsec, , Host, , Host*, , Router, , One or More SAs, , Host*, , Local, Intranet, , Host*, , (d) Case 4, , Internet, , Tunnel SA, , (c) Case 3, , Internet, , Security, Gateway*, , Tunnel SA, , Host*, , Local, Intranet, , Security, Gateway*, , Host*, , One or Two SAs, , Local, Intranet, , Security, Gateway*, , One or Two SAs, , 20.4 / COMBINING SECURITY ASSOCIATIONS, , 683
Page 685 :
684, , CHAPTER 20 / IP SECURITY, , Case 2. Security is provided only between gateways (routers, firewalls, etc.), and no hosts implement IPsec. This case illustrates simple virtual private network, support. The security architecture document specifies that only a single tunnel SA is, needed for this case. The tunnel could support AH, ESP, or ESP with the authentication option. Nested tunnels are not required, because the IPsec services apply to, the entire inner packet., Case 3. This builds on case 2 by adding end-to-end security. The same combinations discussed for cases 1 and 2 are allowed here. The gateway-to-gateway tunnel provides either authentication, confidentiality, or both for all traffic between, end systems. When the gateway-to-gateway tunnel is ESP, it also provides a limited, form of traffic confidentiality. Individual hosts can implement any additional IPsec, services required for given applications or given users by means of end-to-end SAs., Case 4. This provides support for a remote host that uses the Internet to reach, an organization’s firewall and then to gain access to some server or workstation, behind the firewall. Only tunnel mode is required between the remote host and the, firewall. As in case 1, one or two SAs may be used between the remote host and the, local host., , 20.5 INTERNET KEY EXCHANGE, The key management portion of IPsec involves the determination and distribution, of secret keys. A typical requirement is four keys for communication between two, applications: transmit and receive pairs for both integrity and confidentiality. The, IPsec Architecture document mandates support for two types of key management:, ■, , ■, , Manual: A system administrator manually configures each system with its own, keys and with the keys of other communicating systems. This is practical for, small, relatively static environments., Automated: An automated system enables the on-demand creation of keys for, SAs and facilitates the use of keys in a large distributed system with an evolving configuration., , The default automated key management protocol for IPsec is referred to as, ISAKMP/Oakley and consists of the following elements:, ■, , ■, , Oakley Key Determination Protocol: Oakley is a key exchange protocol based, on the Diffie–Hellman algorithm but providing added security. Oakley is generic in that it does not dictate specific formats., Internet Security Association and Key Management Protocol (ISAKMP):, ISAKMP provides a framework for Internet key management and provides, the specific protocol support, including formats, for negotiation of security, attributes., , ISAKMP by itself does not dictate a specific key exchange algorithm; rather,, ISAKMP consists of a set of message types that enable the use of a variety of key, exchange algorithms. Oakley is the specific key exchange algorithm mandated for, use with the initial version of ISAKMP.
Page 686 :
20.5 / INTERNET KEY EXCHANGE, , 685, , In IKEv2, the terms Oakley and ISAKMP are no longer used, and there, are significant differences from the use of Oakley and ISAKMP in IKEv1., Nevertheless, the basic functionality is the same. In this section, we describe the, IKEv2 specification., , Key Determination Protocol, IKE key determination is a refinement of the Diffie–Hellman key exchange algorithm. Recall that Diffie–Hellman involves the following interaction between users, A and B. There is prior agreement on two global parameters: q, a large prime number; and a, a primitive root of q. A selects a random integer XA as its private key and, transmits to B its public key ΥA = aXA mod q. Similarly, B selects a random integer, XB as its private key and transmits to A its public key ΥB = aXB mod q. Each side, can now compute the secret session key:, K = (ΥB)XA mod q = (ΥA)XB mod q = aXAXB mod q, The Diffie–Hellman algorithm has two attractive features:, ■, ■, , Secret keys are created only when needed. There is no need to store secret, keys for a long period of time, exposing them to increased vulnerability., The exchange requires no pre-existing infrastructure other than an agreement, on the global parameters., , However, there are a number of weaknesses to Diffie–Hellman, as pointed out in, [HUIT98]., ■, ■, , ■, , It does not provide any information about the identities of the parties., It is subject to a man-in-the-middle attack, in which a third party C impersonates B while communicating with A and impersonates A while communicating, with B. Both A and B end up negotiating a key with C, which can then listen to, and pass on traffic. The man-in-the-middle attack proceeds as, 1. B sends his public key YB in a message addressed to A (see Figure 10.2)., 2. The enemy (E) intercepts this message. E saves B’s public key and sends a, message to A that has B’s User ID but E’s public key YE. This message is, sent in such a way that it appears as though it was sent from B’s host system., A receives E’s message and stores E’s public key with B’s User ID. Similarly,, E sends a message to B with E’s public key, purporting to come from A., 3. B computes a secret key K1 based on B’s private key and YE. A computes, a secret key K2 based on A’s private key and YE. E computes K1 using E’s, secret key XE and YB and computers K2 using XE and YA., 4. From now on, E is able to relay messages from A to B and from B to A,, appropriately changing their encipherment en route in such a way that neither A nor B will know that they share their communication with E., It is computationally intensive. As a result, it is vulnerable to a clogging attack,, in which an opponent requests a high number of keys. The victim spends considerable computing resources doing useless modular exponentiation rather, than real work., , Hiva-Network.Com
Page 687 :
686, , CHAPTER 20 / IP SECURITY, , IKE key determination is designed to retain the advantages of Diffie–Hellman,, while countering its weaknesses., FEATURES OF IKE KEY DETERMINATION The IKE key determination algorithm is, characterized by five important features:, 1. It employs a mechanism known as cookies to thwart clogging attacks., 2. It enables the two parties to negotiate a group; this, in essence, specifies the, global parameters of the Diffie–Hellman key exchange., 3. It uses nonces to ensure against replay attacks., 4. It enables the exchange of Diffie–Hellman public key values., 5. It authenticates the Diffie–Hellman exchange to thwart man-in-the-middle, attacks., We have already discussed Diffie–Hellman. Let us look at the remainder of, these elements in turn. First, consider the problem of clogging attacks. In this attack, an opponent forges the source address of a legitimate user and sends a public, Diffie–Hellman key to the victim. The victim then performs a modular exponentiation to compute the secret key. Repeated messages of this type can clog the victim’s system with useless work. The cookie exchange requires that each side send, a pseudorandom number, the cookie, in the initial message, which the other side, acknowledges. This acknowledgment must be repeated in the first message of the, Diffie–Hellman key exchange. If the source address was forged, the opponent gets, no answer. Thus, an opponent can only force a user to generate acknowledgments, and not to perform the Diffie–Hellman calculation., IKE mandates that cookie generation satisfy three basic requirements:, 1. The cookie must depend on the specific parties. This prevents an attacker from, obtaining a cookie using a real IP address and UDP port and then using it to, swamp the victim with requests from randomly chosen IP addresses or ports., 2. It must not be possible for anyone other than the issuing entity to generate, cookies that will be accepted by that entity. This implies that the issuing entity, will use local secret information in the generation and subsequent verification, of a cookie. It must not be possible to deduce this secret information from any, particular cookie. The point of this requirement is that the issuing entity need, not save copies of its cookies, which are then more vulnerable to discovery, but, can verify an incoming cookie acknowledgment when it needs to., 3. The cookie generation and verification methods must be fast to thwart attacks, intended to sabotage processor resources., The recommended method for creating the cookie is to perform a fast hash, (e.g., MD5) over the IP Source and Destination addresses, the UDP Source and, Destination ports, and a locally generated secret value., IKE key determination supports the use of different groups for the Diffie–, Hellman key exchange. Each group includes the definition of the two global parameters and the identity of the algorithm. The current specification includes the, following groups.
Page 688 :
20.5 / INTERNET KEY EXCHANGE, ■, , 687, , Modular exponentiation with a 768-bit modulus, q = 2768 - 2704 - 1 + 264 * ( : 2638 * p ; + 149686), a = 2, , ■, , Modular exponentiation with a 1024-bit modulus, q = 21024 - 2960 - 1 + 264 * ( : 2894 * p ; + 129093), a = 2, , ■, , Modular exponentiation with a 1536-bit modulus, ■ Parameters to be determined, , ■, , Elliptic curve group over 2155, ■ Generator (hexadecimal): X = 7B, Y = 1C8, ■ Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F, , ■, , Elliptic curve group over 2185, ■, ■, , Generator (hexadecimal): X = 18, Y = D, Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9, , The first three groups are the classic Diffie–Hellman algorithm using modular, exponentiation. The last two groups use the elliptic curve analog to Diffie–Hellman,, which was described in Chapter 10., IKE key determination employs nonces to ensure against replay attacks. Each, nonce is a locally generated pseudorandom number. Nonces appear in responses, and are encrypted during certain portions of the exchange to secure their use., Three different authentication methods can be used with IKE key determination:, ■, , ■, ■, , Digital signatures: The exchange is authenticated by signing a mutually obtainable hash; each party encrypts the hash with its private key. The hash is, generated over important parameters, such as user IDs and nonces., Public-key encryption: The exchange is authenticated by encrypting parameters such as IDs and nonces with the sender’s private key., Symmetric-key encryption: A key derived by some out-of-band mechanism, can be used to authenticate the exchange by symmetric encryption of exchange parameters., , IKEV2 EXCHANGES The IKEv2 protocol involves the exchange of messages, in pairs. The first two pairs of exchanges are referred to as the initial exchanges, (Figure 20.11a). In the first exchange, the two peers exchange information concerning cryptographic algorithms and other security parameters they are willing to use, along with nonces and Diffie–Hellman (DH) values. The result of this exchange is to, set up a special SA called the IKE SA (see Figure 20.2). This SA defines parameters, for a secure channel between the peers over which subsequent message exchanges, take place. Thus, all subsequent IKE message exchanges are protected by encryption and message authentication. In the second exchange, the two parties authenticate one another and set up a first IPsec SA to be placed in the SADB and used for
Page 690 :
20.5 / INTERNET KEY EXCHANGE, Bit:, , 0, , 8, , 16, , 689, , 31, , 24, , Initiator’s Security Parameter Index (SPI), , Responder’s Security Parameter Index (SPI), Next Payload, , MjVer, , MnVer Exchange Type, , Flags, , Message ID, Length, (a) IKE header, Bit:, , 0, , 8, , Next Payload, , 31, , 16, , C RESERVED, , Payload Length, , (b) Generic Payload header, , Figure 20.12, , IKE Formats, , Figure 20.12a shows the header format for an IKE message. It consists of the, following fields., ■, ■, ■, ■, ■, ■, ■, , ■, ■, , Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKE, security association (SA)., Responder SPI (64 bits): A value chosen by the responder to identify a unique, IKE SA., Next Payload (8 bits): Indicates the type of the first payload in the message;, payloads are discussed in the next subsection., Major Version (4 bits): Indicates major version of IKE in use., Minor Version (4 bits): Indicates minor version in use., Exchange Type (8 bits): Indicates the type of exchange; these are discussed, later in this section., Flags (8 bits): Indicates specific options set for this IKE exchange. Three bits, are defined so far. The initiator bit indicates whether this packet is sent by, the SA initiator. The version bit indicates whether the transmitter is capable, of using a higher major version number than the one currently indicated. The, response bit indicates whether this is a response to a message containing the, same message ID., Message ID (32 bits): Used to control retransmission of lost packets and, matching of requests and responses., Length (32 bits): Length of total message (header plus all payloads) in octets., , IKE PAYLOAD TYPES All IKE payloads begin with the same generic payload header, shown in Figure 20.12b. The Next Payload field has a value of 0 if this is the last
Page 691 :
690, , CHAPTER 20 / IP SECURITY, , payload in the message; otherwise its value is the type of the next payload. The, Payload Length field indicates the length in octets of this payload, including the, generic payload header., The critical bit is 0 if the sender wants the recipient to skip this payload if it, does not understand the payload type code in the Next Payload field of the previous, payload. It is set to 1 if the sender wants the recipient to reject this entire message if, it does not understand the payload type., Table 20.3 summarizes the payload types defined for IKE and lists the fields,, or parameters, that are part of each payload. The SA payload is used to begin the, establishment of an SA. The payload has a complex, hierarchical structure. The, payload may contain multiple proposals. Each proposal may contain multiple protocols. Each protocol may contain multiple transforms. And each transform may, contain multiple attributes. These elements are formatted as substructures within, the payload as follows., ■, , ■, , ■, , Proposal: This substructure includes a proposal number, a protocol ID (AH,, ESP, or IKE), an indicator of the number of transforms, and then a transform, substructure. If more than one protocol is to be included in a proposal, then, there is a subsequent proposal substructure with the same proposal number., Transform: Different protocols support different transform types. The transforms are used primarily to define cryptographic algorithms to be used with a, particular protocol., Attribute: Each transform may include attributes that modify or complete the, specification of the transform. An example is key length., , Table 20.3, , IKE Payload Types, Type, , Parameters, , Security Association, , Proposals, , Key Exchange, , DH Group #, Key Exchange Data, , Identification, , ID Type, ID Data, , Certificate, , Cert Encoding, Certificate Data, , Certificate Request, , Cert Encoding, Certification Authority, , Authentication, , Auth Method, Authentication Data, , Nonce, , Nonce Data, , Notify, , Protocol-ID, SPI Size, Notify Message Type, SPI, Notification Data, , Delete, , Protocol-ID, SPI Size, # of SPIs, SPI (one or more), , Vendor ID, , Vendor ID, , Traffic Selector, , Number of TSs, Traffic Selectors, , Encrypted, , IV, Encrypted IKE payloads, Padding, Pad Length, ICV, , Configuration, , CFG Type, Configuration Attributes, , Extensible Authentication, Protocol, , EAP Message
Page 692 :
20.5 / INTERNET KEY EXCHANGE, , 691, , The Key Exchange payload can be used for a variety of key exchange techniques, including Oakley, Diffie–Hellman, and the RSA-based key exchange used, by PGP. The Key Exchange data field contains the data required to generate a session key and is dependent on the key exchange algorithm used., The Identification payload is used to determine the identity of communicating, peers and may be used for determining authenticity of information. Typically the, ID Data field will contain an IPv4 or IPv6 address., The Certificate payload transfers a public-key certificate. The Certificate, Encoding field indicates the type of certificate or certificate-related information,, which may include the following:, ■, ■, ■, ■, ■, ■, ■, ■, ■, , PKCS #7 wrapped X.509 certificate, PGP certificate, DNS signed key, X.509 certificate—signature, X.509 certificate—key exchange, Kerberos tokens, Certificate Revocation List (CRL), Authority Revocation List (ARL), SPKI certificate, , At any point in an IKE exchange, the sender may include a Certificate Request, payload to request the certificate of the other communicating entity. The payload, may list more than one certificate type that is acceptable and more than one certificate authority that is acceptable., The Authentication payload contains data used for message authentication, purposes. The authentication method types so far defined are RSA digital signature, shared-key message integrity code, and DSS digital signature., The Nonce payload contains random data used to guarantee liveness during, an exchange and to protect against replay attacks., The Notify payload contains either error or status information associated with, this SA or this SA negotiation. The following table lists the IKE notify messages., Error Messages, , Status Messages, , Unsupported Critical, , Initial Contact, , Payload, , Set Window Size, , Invalid IKE SPI, , Additional TS Possible, , Invalid Major Version, , IPCOMP Supported, , Invalid Syntax, , NAT Detection Source IP, , Invalid Payload Type, , NAT Detection Destination IP, , Invalid Message ID, , Cookie, , Invalid SPI, , Use Transport Mode
Page 693 :
692, , CHAPTER 20 / IP SECURITY, Error Messages, , Status Messages, , No Proposal Chosen, , HTTP Cert Lookup Supported, , Invalid KE Payload, , Rekey SA, , Authentication Failed, , ESP TFC Padding Not Supported, , Single Pair Required, , Non First Fragments Also, , No Additional SAS, Internal Address Failure, Failed CP Required, TS Unacceptable, Invalid Selectors, , The Delete payload indicates one or more SAs that the sender has deleted, from its database and that therefore are no longer valid., The Vendor ID payload contains a vendor-defined constant. The constant is, used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility., The Traffic Selector payload allows peers to identify packet flows for processing by IPsec services., The Encrypted payload contains other payloads in encrypted form. The encrypted payload format is similar to that of ESP. It may include an IV if the encryption algorithm requires it and an ICV if authentication is selected., The Configuration payload is used to exchange configuration information between IKE peers., The Extensible Authentication Protocol (EAP) payload allows IKE SAs to, be authenticated using EAP, which was discussed in Chapter 16., , 20.6 CRYPTOGRAPHIC SUITES, The IPsecv3 and IKEv3 protocols rely on a variety of types of cryptographic algorithms. As we have seen in this book, there are many cryptographic algorithms of, each type, each with a variety of parameters, such as key size. To promote interoperability, two RFCs define recommended suites of cryptographic algorithms and, parameters for various applications., RFC 4308 defines two cryptographic suites for establishing virtual private networks. Suite VPN-A matches the commonly used corporate VPN security used in, older IKEv1 implementations at the time of the issuance of IKEv2 in 2005. Suite, VPN-B provides stronger security and is recommended for new VPNs that implement IPsecv3 and IKEv2., Table 20.4a lists the algorithms and parameters for the two suites. There are, several points to note about these two suites. Note that for symmetric cryptography,
Page 695 :
694, , CHAPTER 20 / IP SECURITY, , Table 20.4b lists the algorithms and parameters for the two suites. As with, RFC 4308, three categories of secret key algorithms are listed:, ■, , ■, , ■, , Encryption: For ESP, authenticated encryption is provided using the GCM, mode with either 128-bit or 256-bit AES keys. For IKE encryption, CBC is, used, as it was for the VPN suites., Message authentication: For ESP, if only authentication is required, then, GMAC is used. As discussed in Chapter 12, GMAC is simply the authentication portion of GMC. For IKE, message authentication is provided using, HMAC with one of the SHA-3 hash functions., Pseudorandom function: As with the VPN suites, IKEv2 in these suites generates pseudorandom bits by repeated use of the MAC used for message, authentication., , For the Diffie–Hellman algorithm, the use of elliptic curve groups modulo, a prime is specified. For authentication, elliptic curve digital signatures are listed., The original IKEv2 documents used RSA-based digital signatures. Equivalent or, greater strength can be achieved using ECC with fewer key bits., , 20.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, Key Terms, anti-replay service, Authentication Header (AH), Encapsulating Security, Payload (ESP), Internet Key Exchange, (IKE), , Internet Security Association, and Key Management, Protocol (ISAKMP), IP Security (IPsec), IPv4, IPv6, , Oakley key determination, protocol, replay attack, security association (SA), transport mode, tunnel mode, , Review Questions, 20.1, 20.2, 20.3, 20.4, 20.5, 20.6, 20.7, 20.8, , List and briefly describe some benefits of IPsec., List and briefly define different categories of IPsec documents., What parameters identify an SA and what parameters characterize the nature of a, particular SA?, What is the difference between transport mode and tunnel mode?, What are the types of secret key algorithm used in IPsec?, Why does ESP include a padding field?, What are the basic approaches to bundling SAs?, What are the roles of the Oakley key determination protocol and ISAKMP in IPsec?, , Hiva-Network.Com
Page 696 :
20.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS, , 695, , Problems, 20.1, 20.2, 20.3, 20.4, , 20.5, , 20.6, , 20.7, , 20.8, , 20.9, 20.10, , Describe and explain each of the entries in Table 20.2., Draw a figure similar to Figure 20.8 for AH., List the major security services provided by AH and ESP, respectively., In discussing AH processing, it was mentioned that not all of the fields in an IP header, are included in MAC calculation., a. For each of the fields in the IPv4 header, indicate whether the field is immutable,, mutable but predictable, or mutable (zeroed prior to ICV calculation)., b. Do the same for the IPv6 header., c. Do the same for the IPv6 extension headers., In each case, justify your decision for each field., Suppose that the current replay window spans from 120 to 530., a. If the next incoming authenticated packet has sequence number 340, what will the, receiver do with the packet, and what will be the parameters of the window after, that?, b. If instead the next incoming authenticated packet has sequence number 598, what, will the receiver do with the packet, and what will be the parameters of the window after that?, c. If instead the next incoming authenticated packet has sequence number 110, what, will the receiver do with the packet, and what will be the parameters of the window after that?, When tunnel mode is used, a new outer IP header is constructed. For both IPv4, and IPv6, indicate the relationship of each outer IP header field and each extension, header in the outer packet to the corresponding field or extension header of the inner, IP packet. That is, indicate which outer values are derived from inner values and, which are constructed independently of the inner values., End-to-end authentication and encryption are desired between two hosts. Draw, figures similar to Figure 20.8 that show each of the following., a. Transport adjacency with encryption applied before authentication., b. A transport SA bundled inside a tunnel SA with encryption applied before, authentication., c. A transport SA bundled inside a tunnel SA with authentication applied before, encryption., The IPsec architecture document states that when two transport mode SAs are, bundled to allow both AH and ESP protocols on the same end-to-end flow, only, one ordering of security protocols seems appropriate: performing the ESP protocol, before performing the AH protocol. Why is this approach recommended rather than, authentication before encryption?, For the IKE key exchange, indicate which parameters in each message go in which, ISAKMP payload types., Where does IPsec reside in a protocol stack?
Page 697 :
APPENDIX A, PROJECTS FOR TEACHING CRYPTOGRAPHY, #0&|0'6914-5'%74+6;, A.1 Sage Computer Algebra Projects, A.2 Hacking Project, A.3 Block Cipher Projects, A.4 Laboratory Exercises, A.5 Research Projects, A.6 Programming Projects, A.7 Practical Security Assessments, A.8 Firewall Projects, A.9 Case Studies, A.10 Writing Assignments, A.11 Reading/Report Assignments, A.12 Discussion Topics, , 696
Page 698 :
A.1 / SAGE COMPUTER ALGEBRA PROJECTS, , 697, , Analysis and observation, theory and experience must never disdain or exclude, each other; on the contrary, they support each other., —On War, Carl Von Clausewitz, Many instructors believe that research or implementation projects are crucial to the, clear understanding of cryptography and network security. Without projects, it may, be difficult for students to grasp some of the basic concepts and interactions among, components. Projects reinforce the concepts introduced in the book, give the student a greater appreciation of how a cryptographic algorithm or protocol works,, and can motivate students and give them confidence that they are capable of not, only understanding but implementing the details of a security capability., In this text, I have tried to present the concepts of cryptography and network, security as clearly as possible and have provided numerous homework problems to, reinforce those concepts. However, many instructors will wish to supplement this, material with projects. This appendix provides some guidance in that regard and, describes support material available in the Instructor’s Resource Center (IRC) for, this book, accessible to instructors from Pearson Education. The support material, covers 12 types of projects and other student exercises:, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, ■, , Sage computer algebra projects, Hacking project, Block cipher projects, Laboratory exercises, Research projects, Programming projects, Practical security assessments, Firewall projects, Case studies, Writing assignments, Reading/report assignments, Discussion topics, , A.1 SAGE COMPUTER ALGEBRA PROJECTS, One of the most important new features for this edition is the use of Sage for cryptographic examples and homework assignments. Sage is an open-source, multiplatform, freeware package that implements a very powerful, flexible, and easily learned, mathematics and computer algebra system. A computer algebra system (CAS) is, software that can perform symbolic as well as numerical calculations. CASs have, been used for teaching since their inception some decades ago, and there is now, a considerable literature on their use. A CAS is a natural tool for extending the, learning experience in a cryptography course.
Page 699 :
698, , APPENDIX A / PROJECTS FOR TEACHING CRYPTOGRAPHY, , Unlike competing systems such as Mathematica, Maple, and MATLAB, there, are no licensing agreements or fees involved with Sage. Thus, Sage can be made, available on computers and networks at school, and students can individually download the software to their own personal computers for use at home. Another advantage of using Sage is that students learn a powerful, flexible tool that can be used for, virtually any mathematical application, not just cryptography. The Sage Web site, (http://www.sagemath.org) provides considerable documentation on how to install,, set up, and use Sage on a variety of computers and how to use it online via the Web., The use of Sage can make a significant difference to the teaching of the, mathematics of cryptographic algorithms. Appendix B provides a large number of, examples of the use of Sage covering many cryptographic concepts. Appendix C lists, exercises in each of these topic areas to enable the student to gain hands-on experience with cryptographic algorithms. Copies of both appendices are available online, so that students do not have to key in lines of code that are printed in the appendices., The IRC contains solutions to all of the exercises in Appendix C., Dan Shumow of Microsoft and the University of Washington developed all of, the examples and assignments in Appendices B and C., , A.2 HACKING PROJECT, The aim of this project is to hack into a corporation’s network through a series of, steps. The corporation is named Extreme In Security Corporation. As the name, indicates, the corporation has some security holes in it, and a clever hacker is able, to access critical information by hacking into its network. The IRC includes what is, needed to set up the Web site. The student’s goal is to capture the secret information about the price on the quote the corporation is placing next week to obtain, a contract for a governmental project., The student should start at the Web site and find his or her way into the, network. At each step, if the student succeeds, there are indications as to how to, proceed on to the next step as well as the grade until that point., The project can be attempted in three ways:, 1. Without seeking any sort of help, 2. Using some provided hints, 3. Using exact directions, The IRC includes the files needed for this project:, 1. Web Security project, 2. Web Hacking exercises (XSS and Script-attacks) covering client-side and, server-side vulnerability exploitations, respectively, 3. Documentation for installation and use for the above, 4. A PowerPoint file describing Web hacking. This file is crucial to understanding how to use the exercises since it clearly explains the operation using, screen shots.
Page 700 :
A.5 / RESEARCH PROJECTS, , 699, , This project was designed and implemented by Professor Sreekanth Malladi, of Dakota State University., , A.3 BLOCK CIPHER PROJECTS, This is a lab that explores the operation of the AES encryption algorithm by tracing, its execution, computing one round by hand, and then exploring the various block, cipher modes of use. The lab also covers DES. In both cases, an online Java applet, is used (or can be downloaded) to execute AES or DES., For both AES and DES, the lab is divided into three separate parts:, ■, , ■, ■, , Block cipher internals: This part involves encrypting plaintext and analyzing, the intermediate results after each round. There is an online calculator for both, AES and DES that provides the intermediate results and the final ciphertext., Block cipher round: This part involves calculating one round by hand and, comparing the results to those produced by the calculator., Block cipher modes of use: Enables the student to compare the operation of, CBC and CFB modes., , The IRC contains the .html and .jar files needed to set up these labs on your, own Web site. Alternatively, the material is available from the Student Resources, section of this book’s Web site. Click on the rotating globe., Lawrie Brown of the Australian Defence Force Academy developed these, projects., , A.4 LABORATORY EXERCISES, Professor Sanjay Rao and Ruben Torres of Purdue University have prepared a set, of laboratory exercises that are included in the IRC. These are implementation, projects designed to be programmed on Linux but could be adapted for any, Unix environment. These laboratory exercises provide realistic experience in, implementing security functions and applications., , A.5 RESEARCH PROJECTS, An effective way of reinforcing basic concepts from the course and for teaching, students research skills is to assign a research project. Such a project could involve, a literature search as well as an Internet search of vendor products, research lab, activities, and standardization efforts. Projects could be assigned to teams or, for, smaller projects, to individuals. In any case, it is best to require some sort of project, proposal early in the term, giving the instructor time to evaluate the proposal for, appropriate topic and appropriate level of effort. Student handouts for research, projects should include
Page 701 :
700, , APPENDIX A / PROJECTS FOR TEACHING CRYPTOGRAPHY, ■, ■, ■, ■, , A format for the proposal, A format for the final report, A schedule with intermediate and final deadlines, A list of possible project topics, , The students can select one of the topics listed in the IRC or devise their own, comparable project. The IRC includes a suggested format for the proposal and final, report as well as a list of 15 possible research topics., , A.6 PROGRAMMING PROJECTS, The programming project is a useful pedagogical tool. There are several attractive, features of stand-alone programming projects that are not part of an existing, security facility:, 1. The instructor can choose from a wide variety of cryptography and network, security concepts to assign projects., 2. The projects are platform and language independent. Students can program, the projects on any available computer and in any appropriate language., 3. The instructor need not download, install, and configure any particular infrastructure for stand-alone projects., There is also flexibility in the size of projects. Larger projects give students, more a sense of achievement, but students with less ability or fewer organizational, skills can be left behind. Larger projects usually elicit more overall effort from, the best students. Smaller projects can have a higher concepts-to-code ratio and,, because more of them can be assigned, the opportunity exists to address a variety, of different areas., Again, as with research projects, the students should first submit a proposal., The student handout should include the same elements listed in the preceding, section. The IRC includes a set of 12 possible programming projects., The following individuals have supplied the research and programming projects suggested in the IRC: Henning Schulzrinne of Columbia University; Cetin Kaya, Koc of Oregon State University; and David M. Balenson of Trusted Information, Systems and George Washington University., , A.7 PRACTICAL SECURITY ASSESSMENTS, Examining the current infrastructure and practices of an existing organization is, one of the best ways of developing skills in assessing its security posture. The IRC, contains a list of such activities. Students, working either individually or in small, groups, select a suitable small- to medium-sized organization. They then interview, some key personnel in that organization in order to conduct a suitable selection, of security risk assessment and review tasks as it relates to the organization’s IT
Page 702 :
A.10 / WRITING ASSIGNMENTS, , 701, , infrastructure and practices. As a result, they can then recommend suitable changes,, which can improve the organization’s IT security. These activities help students, develop an appreciation of current security practices and the skills needed to review, these and recommend changes., Lawrie Brown of the Australian Defence Force Academy developed these, projects., , A.8 FIREWALL PROJECTS, The implementation of network firewalls can be a difficult concept for students, to grasp initially. The IRC includes a Network Firewall Visualization tool to convey and teach network security and firewall configuration. This tool is intended to, teach and reinforce key concepts including the use and purpose of a perimeter firewall, the use of separated subnets, the purposes behind packet filtering, and the, shortcomings of a simple packet filter firewall., The IRC includes a .jar file that is fully portable, and a series of exercises., The tool and exercises were developed at U.S. Air Force Academy., , A.9 CASE STUDIES, Teaching with case studies engages students in active learning. The IRC includes, case studies in the following areas:, ■, ■, ■, ■, ■, ■, ■, , Disaster recovery, Firewalls, Incidence response, Physical security, Risk, Security policy, Virtualization, , Each case study includes learning objectives, case description, and a series, of case discussion questions. Each case study is based on real-world situations and, includes papers or reports describing the case., The case studies were developed at North Carolina A&T State University., , A.10 WRITING ASSIGNMENTS, Writing assignments can have a powerful multiplier effect in the learning process, in a technical discipline such as cryptography and network security. Adherents of, the Writing Across the Curriculum (WAC) movement (http://wac.colostate.edu/), report substantial benefits of writing assignments in facilitating learning. Writing, assignments lead to more detailed and complete thinking about a particular topic. In
Page 703 :
702, , APPENDIX A / PROJECTS FOR TEACHING CRYPTOGRAPHY, , addition, writing assignments help to overcome the tendency of students to pursue, a subject with a minimum of personal engagement, just learning facts and problemsolving techniques without obtaining a deep understanding of the subject matter., The IRC contains a number of suggested writing assignments, organized, by chapter. Instructors may ultimately find that this is an important part of their, approach to teaching the material. I would greatly appreciate any feedback on this, area and any suggestions for additional writing assignments., , A.11 READING/REPORT ASSIGNMENTS, Another excellent way to reinforce concepts from the course and to give students, research experience is to assign papers from the literature to be read and analyzed., The student is then asked to write a brief report on the assigned paper. The IRC, includes a suggested list of papers, one or two per chapter, to be assigned. The, IRC provides a PDF copy of each of the papers. The IRC also includes a suggested, assignment wording., , A.12 DISCUSSION TOPICS, One way to provide a collaborative experience is discussion topics, a number of, which are included in the IRC. Each topic relates to material in the book. The, instructor can set it up so that students can discuss a topic either in a class setting,, an online chat room, or a message board. Again, I would greatly appreciate any, feedback on this area and any suggestions for additional discussion topics.
Page 704 :
APPENDIX B, SAGE EXAMPLES, By Dan Shumow, University of Washington, B.1 Linear Algebra and Matrix Functionality, B.2 Chapter 2: Number Theory, B.3 Chapter 3: Classical Encryption, B.4 Chapter 4: Block Ciphers and the Data Encryption Standard, B.5 Chapter 5: Basic Concepts in Number Theory and Finite Fields, B.6 Chapter 6: Advanced Encryption Standard, B.7 Chapter 8: Pseudorandom Number Generation and Stream Ciphers, B.8 Chapter 9: Public-Key Cryptography and RSA, B.9 Chapter 10: Other Public-Key Cryptosystems, B.10 Chapter 11: Cryptographic Hash Functions, B.11 Chapter 13: Digital Signatures, , 703, Hiva-Network.Com
Page 705 :
704, , APPENDIX B / SAGE EXAMPLES, , This appendix contains a number of examples that illustrate cryptographic concepts,, organized by the chapter in which those concepts were discussed. All the examples, are in Sage.1 See Appendix C for how to get started using Sage and for a brief introduction to Sage syntax and operations. We begin with a brief introduction to some, basic Sage matrix and linear algebra operations., You should be able to follow the examples in this section as written. However,, if you have difficulty interpreting the Sage code, please refer to Section C.2, in Appendix C., , B.1 LINEAR ALGEBRA AND MATRIX FUNCTIONALITY, Sage includes linear algebra and matrix functionality. The following shows some of, the basic functionality applicable to cryptography., In Sage you specify a matrix as a list of lists of numbers, passed to the matrix, function. For example, passing a list of lists of integers as follows:, sage: M = matrix([[1, 3],[7,9]]); M, [1 3], [7 9], Alternately, passing a list of lists of rationals as follows:, sage: M = matrix([[1/2, 2/3, 3/4],[5, 7, 8]]); M, [1/2 2/3 3/4], [ 5 7 8], You can specify that the input should be reduced by a modulus, using the, IntegerModRing (functionality to be described later), Sage: R = IntegerModRing(100), sage: M = matrix(R, [[1],[102],[1003]]); M, [1], [2], [3], Or that the input should be considered in a finite field (also to be described, later)., sage: F = GF(2);, sage: M = matrix(F, [[1, 2, 0, 3]]); M, [1 0 0 1], , 1, , All of the Sage code in this appendix is available at this book’s Companion Web site in .sage files, so that, you can load and execute the programs if you wish. See Preface for access information.
Page 706 :
B.2 / NUMBER THEORY, , 705, , Sage also supports multiplication, addition, and inversion of matrices as, follows:, sage: M1 = matrix([[1, 2],[3,4]]);, sage: M2 = matrix([[1,−1],[1, 1]]);, sage: M1*M2, [3 1], [7 1], sage: M1 + M2, [2 1], [4 5], sage: M2^−1, [ 1/2 1/2], [−1/2 1/2], , B.2 CHAPTER 2: NUMBER THEORY, Example 1: Chinese Remainder Theorem., def chinese_remainder_theorem(moduli, residues):, r""", Function that implements the chinese remainder, theorem., INPUT:, moduli − list or positive integers., residues − list of remainders such that remainder, at position j results when divided by the corresponding, modulus at position j in moduli., OUTPUT:, x − integer such that division by moduli[j] gives, remainder residue[j]., """, if (len(moduli) != len(residues)):, raise, ValueError,, len(residues)", M = prod(moduli);, x = 0;, , "expected, , len(moduli), , ==
Page 707 :
706, , APPENDIX B / SAGE EXAMPLES, , for j in xrange(len(moduli)):, Mj = moduli[j], Mpr = M/Mj, (Mj_Mpr_gcd, Mpr_inv, Mj_inv) = xgcd(Mpr, Mj), Mpr_inv = Mpr_inv, if (Mj_Mpr_gcd != 1):, raise ValueError,, coprime.", , "Expected, , all, , moduli, , are, , x += residues[j]*Mpr*Mpr_inv;, return x;, Example 2: Miller–Rabin Primality Test., r""", EXAMPLES:, sage: MILLER_RABIN_TEST(101), False, sage: MILLER_RABIN_TEST(592701729979), True, """, def MILLER_RABIN_TEST(n):, r""", This function implements the Miller-Rabin Test., It either returns "inconclusive" or "composite.", INPUT:, n − positive integer to probabilistically, determine the primality of., OUTPUT:, If the function returns False, then the test was, inconclusive., If the function returns True, then the test was, conclusive and n is composite., """, R = IntegerModRing(n); # object for integers mod n, # (1) Find integers k, q w/ k > 0 and q odd so that, (n−1) == 2^k * q, q = n−1, k = 0
Page 708 :
B.2 / NUMBER THEORY, , 707, , while (1 == (q % 2)):, k += 1, q = q.quo_rem(2)[0] # q/2 but with result of type, Integer, # (2) select random a in 1 < a < n−1, a = randint(1,n−1), a = R(a) # makes it so modular exponentiation is done, fast, # if a^q mod n == 1 then return inconclusive, if (1 == a^q):, return False, # (3) for j = 0 to k−1 do: if a^(2^j * q) mod n = n−1, return inconclusive, e = q, for j in xrange(k):, if (n−1) == (a^e):, return False, e = 2*e, # (4) if you've made it here return composite., return True, Example 3: Modular Exponentiation (Square and Multiply)., def ModExp(x,e,N):, r""", Calculates x^e mod N using square and multiply., INPUT:, x − an integer., e − a nonnegative integer., N − a positive integer modulus., OUTPUT:, y − x^e mod N, """, e_bits = e.bits(), e_bitlen = len(e_bits), y = 1, for j in xrange(e_bitlen):, y = y^2 % N
Page 709 :
708, , APPENDIX B / SAGE EXAMPLES, , if (1 == e_bits[e_bitlen−1−j]):, y = x*y % N, return y, Example 4: Using built-in Sage functionality for CRT., Sage has built in functions to perform the Chinese Remainder Theorem., There are several functions that produce a wide array of CRT functionality., The simplest function performs the CRT with two modulii. Specifically CRT, (or the lowercase crt) when called as:, crt(a,b,m,n), will return a number that is simultaneously congruent to a mod m and b mod n., All parameters are assumed to be integers and the parameters m, n must be, relatively prime. Some examples of this function are:, sage: CRT(8, 16, 17, 49), −3120, sage: CRT(1,2,5,7), 16, sage: CRT(50,64,101,127), −62166, If you want to perform the CRT with a list of residues and moduli, Sage, includes the function CRT_list., CRT_list(v, modulii), requires that v and modulii be lists of integers of the same length. Furthermore,, the elements of modulii must be relatively prime. Then the output is an integer, that reduces to v[i] mod modulii[i] (for i in range(len(v))). For example, the last, call to CRT would have been, sage: CRT_list([50,64],[101,127]), 1969, Note that this answer is different. However, you can check that both answers, satisfy the requirements of the CRT. Here are examples with longer lists:, sage: CRT_list([8, 20, 13], [49, 101, 127]), 608343, sage: CRT_list([10,11,12,13,14],[29,31,37,41,43]), 36657170, The function CRT_basis can be used to precompute the values associated to, the given set of modulii. If modulii is a list of relatively prime modulii, then, CRT_basis(modulii) returns a list a. This list a is such that if x is a list of residues, of the modulii, then the output of the CRT can be found by summing:, a[0]*x[0] + a[1]*x[1] + ... + a[len(a)−1]*x[len(a)−1]
Page 710 :
B.2 / NUMBER THEORY, , 709, , In the case of the modulii used in the last call to CRT_list this function returns, as follows:, sage: CRT_basis([29,31,37,41,43]), [32354576, 20808689, 23774055, 17163708, 23184311], The last CRT function that Sage provides is CRT_vectors. This function, performs CRT_list on several different lists (with the same set of modulii) and, returns a list of the simultaneous answers. It is efficient in that it uses CRT_, basis and does not recompute those values for each list. For example:, sage:, CRT_vectors([[1,10],[2,11],[3,12],[4,13],[5,14]],, [29,31,37,41,43]), [36657161, 36657170], Example 5: Using built-in Sage functionality for Modular Exponentiation., Sage can perform modular exponentiation using fast algorithms (like, square and multiply) and without allowing the intermediate computations, to become huge. This is done through IntegerModRing objects. Specifically,, creating an IntegerModRing object indicates that arithmetic should be done, with a modulus. Then you cast your integers in this ring to indicate that all, arithmetic should be done with the modulus. Then for elements of this ring,, exponentiation is done efficiently. For example:, sage: R = IntegerModRing(101), sage: x = R(10), sage: x^99, 91, sage: R = IntegerModRing(1024), sage: x = R(111), sage: x^345, 751, sage: x = R(100), sage: x^200, 0, sage:, sage:, sage:, sage:, 9177, , N = 127*101, R = IntegerModRing(N), x = R(54), x^95, , Creating an IntegerModRing is similar to creating a FiniteField with GF(...), except that the modulus can be a general composite., Example 6: Using built-in Sage functionality for Euler’s totient., Sage has the Euler totient functionality built in. The function is called, euler_phi because of the convention of using the Greek letter phi to represent
Page 711 :
710, , APPENDIX B / SAGE EXAMPLES, , this function. The operation of this function is simple. Just call euler_phi on an, integer and it computes the totient function. This function factors the input,, and hence requires exponential time., sage: euler_phi(101), 100, sage: euler_phi(1024), 512, sage: euler_phi(333), 216, sage: euler_phi(125), 100, sage: euler_phi(423), 276, , B.3 CHAPTER 3: CLASSICAL ENCRYPTION, The following functions are useful for classical cipher examples and exercises:, en_alphabet = "abcdefghijklmnopqrstuvwxyz", #, # This function returns true if and only if the character, c is an, # alphabetic character, #, def is_alphabetic_char(c):, return (c.lower() in en_alphabet), #, # This function converts a single character into its, numeric value, #, def char_to_num(c):, return en_alphabet.index(c.lower()), #, # This function returns the character corresponding to x, mod 26, # in the English alphabet, #, def num_to_char(x):, return en_alphabet[x % 26], Example 1: Implement Sage encryption/decryption functions that take a key, (as an integer in 0, 1, 2, . . . , 25), and a string. The function should only operate
Page 715 :
714, , APPENDIX B / SAGE EXAMPLES, , P10_data = [3, 5, 2, 7, 4, 10, 1, 9, 8, 6];, P8_data = [6, 3, 7, 4, 8, 5, 10, 9];, LS1_data = [2, 3, 4, 5, 1];, LS2_data = [3, 4, 5, 1, 2];, IP_data = [2, 6, 3, 1, 4, 8, 5, 7];, IPinv_data = [4, 1, 3, 5, 7, 2, 8, 6];, EP_data = [4, 1, 2, 3, 2, 3, 4, 1];, P4_data = [2, 4, 3, 1];, SW_data = [5, 6, 7, 8, 1, 2, 3, 4];, #, # SDES lookup tables, #, S0_data = [[1, 0, 3, 2],, [3, 2, 1, 0],, [0, 2, 1, 3],, [3, 1, 3, 2]];, S1_data = [[0, 1, 2, 3],, [2, 0, 1, 3],, [3, 0, 1, 0],, [2, 1, 0, 3]];, def ApplyPermutation(X, permutation):, r""", This function takes a permutation list (list of, bit positions.), And outputs a bit list with the bits taken from X., """, # permute the list X, l = len(permutation);, return [X[permutation[j]−1] for j in xrange(l)];, def ApplySBox(X, SBox):, r""", This function Applies the SDES SBox (by table, look up, """, r = 2*X[0] + X[3];, c = 2*X[1] + X[2];, o = SBox[r][c];, return [o & 2, o & 1];
Page 719 :
718, , APPENDIX B / SAGE EXAMPLES, , OUTPUT:, g − greatest common divisor of a and b, """, if (b < 0) or ( a <= b):, raise ValueError, "Expected 0 < a < b", (A, B) = (a,b);, while (True):, if (0 == B):, return A;, R = A % B;, A = B;, B = R;, Example 2: The extended Euclidean algorithm for the greatest common, divisor., def EXTENDED_EUCLID(m,b):, r""", The extended Euclidean algorithm to find gcd(m,b)., The input is expected to be such that 0 <= b < m., INPUT:, m − positive integer, b − nonnegative integer less than m, OUTPUT:, (g, b_inv) − g is the gcd of m and b, b_inv is, the multiplicative inverse of b mod m., """, if (m < b) or (b < 0):, raise ValueError, "Expected input (0 < b < m)", (A1,A2,A3) = (1,0,m);, (B1,B2,B3) = (0,1,b);, while (True):, if (0 == B3):, return (A3, None), if (1 == B3):, return (B3, B2), Q = floor(A3/B3), (T1,T2,T3) = (A1−Q*B1, A2−Q*B2, A3−Q*B3)
Page 720 :
B.5 / BASIC CONCEPTS IN NUMBER THEORY AND FINITE FIELDS, , 719, , (A1, A2, A3) = (B1, B2, B3), (B1, B2, B3) = (T1, T2, T3), Example 3: Euclidean algorithm to find gcd of polynomials (with coefficients, in a field)., def POLYNOMIAL_EUCLID(A, B):, r""", Euclidian algorithm for polynomial GCD:, Given two polynomials over the same base field,, Assuming degree(A) => degree(B) => 0., INPUT:, A − polynomial over a field., B − polynomial over the same field as A, and 0 <=, degree(B) <= degree(A)., OUTPUT:, G − greatest common divisor of A and B., """, degA = A.degree();, degB = B.degree();, if ((degB < 0) or (degA < degB)):, raise ValueError, "Expected 0 <= degree(B) <=, degree(A)", while(True):, if (0 == B):, return A;, R = A % B;, A = B;, B = R;, Example 4: Extended Euclidean algorithm for the gcd of two polynomials, (with coefficients in the same field)., def POLYNOMIAL_EXTENDED_EUCLID(m, b):, r""", Extended Euclidian algorithm for polynomial GCD:, Given two polynomials over the same base field,, Assuming degree(m) => degree(b) => 0, INPUT:, m − polynomial over a field.
Page 722 : B.5 / BASIC CONCEPTS IN NUMBER THEORY AND FINITE FIELDS, , 721, , is the gcd, the second and third elements are coefficients u, v such that, gcd(a,b) = u* a + v* b. This can be called as:, sage: xgcd(17,31), (1, 11, −6), sage: xgcd(10, 115), (5, −11, 1), This can also be called as a method on Integer objects, sage: x = 300, sage: x.xgcd(36), (12, 1, −8), Example 6: Sage includes robust support for working with finite fields and, performing finite field arithmetic. To initialize a finite field with prime order,, use the GF command passing the order as the parameter., sage: F = GF(2), sage: F, Finite Field of size 2, sage: F = GF(37), sage: F, Finite Field of size 37, sage: p = 95131, sage: K = GF(p), sage: K, Finite Field of size 95131, To initialize a field with a prime power order use the GF command with, the following syntax (to keep track of the primitive element of the extension, field)., sage: F.<a> = GF(128), sage: F, Finite Field in a of size 2^7, To do arithmetic in finite fields use the following syntax:, sage:, sage:, sage:, sage:, 22, sage:, 21, sage:, 17, sage:, 31, , Hiva-Network.Com, , K, a, b, a, , =, =, =, −, , GF(37), K(3), K(18), b, , a + b, a * b, a/b
Page 723 : 722, , APPENDIX B / SAGE EXAMPLES, , sage: a^−1, 25, sage: 1/a, 25, To do arithmetic in a finite field with a prime power order, specify, elements using the primitive element:, sage:, sage:, sage:, sage:, a^5 +, sage:, a^5 +, sage:, a^3 +, sage:, a^5 +, sage:, a^5 +, sage:, a^5 +, , F.<a> = GF(128), b = a^2 + 1, c = a^5 + a^3 + 1, b − c, a^3 + a^2, b + c, a^3 + a^2, b*c, a^2 + a, b/c, a^3 + a^2 + a, b^−1, a^3 + a, 1/b, a^3 + a, , Example 7: With Sage you can create rings of polynomials over finite fields and do, arithmetic with them. To create polynomial rings over finite fields do the following:, sage: R.<x> = GF(2)[], sage: R, Univariate Polynomial Ring in x over Finite Field of, size 2 (using NTL), sage: R.<x> = GF(101)[], sage: R, sage: R.<x> = F[], sage: R, Univariate Polynomial Ring in x over Finite Field in, a of size 2^7, After initializing a polynomial ring, you can then just perform arithmetic, as you would expect:, sage:, sage:, sage:, sage:, x^5 +, sage:, x^8 +, , R.<x> = GF(2)[], f = x^3 + x + 1, g = x^5 + x, f + g, x^3 + 1, f*g, x^6 + x^5 + x^4 + x^2 + x
Page 724 : B.5 / BASIC CONCEPTS IN NUMBER THEORY AND FINITE FIELDS, , 723, , Division is accomplished by the quo_rem function:, sage: g.quo_rem(f), (x^2 + 1, x^2 + 1), You can also compute the greatest common divisor:, sage: f.gcd(g), 1, sage: g.gcd(g^2), x^5 + x, sage: R.<x> = GF(17)[], sage: f = 3*x^3 + 2*x^2 + x, sage: g = x^2 + 5, sage: f − g, 3*x^3 + x^2 + x + 12, sage: f * g, 3*x^5 + 2*x^4 + 16*x^3 + 10*x^2 + 5*x, sage: f.quo_rem(g), (3*x + 2, 3*x + 7), And computing gcds in this polynomial ring we see:, sage: f.gcd(g), 1, sage: f.gcd(x^2 + x), x, When creating a Sage finite field with a prime power order, Sage finds an, irreducible polynomial for you. For example:, sage: F.<a> = GF(32), a^5 + a^2 + 1, However, there are many irreducible polynomials over GF(2) of degree 5, such, as x^5 + x^3 + 1. Suppose that you want to create your own extension of the, binary field with degree 5, and an irreducible polynomial of your choice. Then, you can do so as follows:, sage: R.<x> = GF(2)[], sage: F = GF(2).extension(x^5 + x^3 + 1, 'a'), sage: a = F.gen(), You need to do this last step to inject the primitive element into the, interpreter’s name space. This is done automatically when using the GF, function to create an extension field, but not when you use the member, function extension on a field object.
Page 725 : 724, , APPENDIX B / SAGE EXAMPLES, , B.6 CHAPTER 6: ADVANCED ENCRYPTION STANDARD, Example 1: Simplified AES., #, #, #, #, #, , These structures are the underlying, Galois Field and corresponding Vector Space, of the field used in the SAES algorithm, These structures allow us to easily compute with these fields., , #, F = GF(2);, L.<a> = GF(2^4);, V = L.vector_space();, VF8 = VectorSpace(F, 8);, #, # The MixColumns and its Inverse matrices are stored, # as 2x2 matrices with elements in GF(2^4) (as are state, matrices.), # The MixColumns operation (and its inverse) are performed by, # matrix multiplication., #, MixColumns_matrix = Matrix(L, [[1,a^2],[a^2,1]]);, InverseMixColumns_matrix = MixColumns_matrix.inverse();, SBox_matrix = Matrix(L,, [, [, 1 + a^3,, a^2,, a + a^3,1 + a, [ 1 + a^2 + a^3,, 1,, a^3,, 1, [, a + a^2,, 0,, a,, [, a^2 + a^3, a + a^2 + a^3, 1 + a + a^2 + a^3,, ]);, , +, +, 1, 1, , a^3],, a^2],, + a],, + a + a^2], , InverseSBox_matrix = Matrix(L,, [, [, a + a^3,, 1 + a^2,, 1 + a^3,, 1 + a + a^3],, [, 1, 1 + a + a^2,, a^3, 1 + a + a^2 + a^3],, [, a + a^2,, 0,, a,, 1 + a],, [ a^2 + a^3,, a^2, 1 + a^2 + a^3,, a + a^2 + a^3], ]);, RCON = [, VF8([F(0), F(0), F(0), F(0), F(0), F(0), F(0), F(1)]),, VF8([F(0), F(0), F(0), F(0), F(1), F(1), F(0), F(0)]), ];
Page 726 :
B.6 / ADVANCED ENCRYPTION STANDARD, , 725, , def SAES_ToStateMatrix(block):, r""", Converts a bit list into an SAES state matrix., """, B = block;, # form the plaintext block into a matrix of GF(2^n), elements, S00 = L(V([B[0], B[1], B[2], B[3]]));, S01 = L(V([B[4], B[5], B[6], B[7]]));, S10 = L(V([B[8], B[9], B[10], B[11]]));, S11 = L(V([B[12], B[13], B[14], B[15]]));, state_matrix = Matrix(L, [[S00,S01],[S10,S11]]);, return state_matrix;, def SAES_FromStateMatrix(State Matrix):, r""", Converts an SAES State Matrix to a bit list., """, output = [];, # convert State Matrix back into bit list, for r in xrange(2):, for c in xrange(2):, v = V(State Matrix[r,c]);, for j in xrange(4):, output.append(Integer(v[j]));, return output;, def SAES_AddRoundKey(state_matrix, K):, r""", Adds a round key to an SAES state matrix., """, K_matrix = SAES_ToStateMatrix(K);, next_state_matrix = K_matrix + state_matrix;, return next_state_matrix;, def SAES_MixColumns(state_matrix):, r""", Performs the Mix Columns operation., """, next_state_matrix = MixColumns_matrix*state_matrix;, return next_state_matrix;
Page 731 :
730, , APPENDIX B / SAGE EXAMPLES, , # way to generate primes, because we do not know how the, # internal sage random_prime function works., p = 3;, while (p < 2^(bitlen−1)) or (3 != (p % 4)):, p = random_prime(2^bitlen);, q = 3;, while (q < 2^(bitlen−1)) or (3 != (q % 4)):, q = random_prime(2^bitlen);, N = p*q;, X = (seed^2 % N), state = [N, X], return state;, def BlumBlumShub_Generate(num_bits, state):, r""", Blum−Blum−Shum random number generation function., INPUT:, num_bits − the number of bits (iterations) to, generate with this RNG., state − an internal state of the BBS−RNG (a list, [N, X].), OUTPUT:, random_bits − a num_bits length list of random, bits., """, random_bits = [];, N = state[0], X = state[1], for j in xrange(num_bits):, X = X^2 % N, random_bits.append(X % 2), # update the internal state, state[1] = X;, return random_bits;, Example 2: Linear Congruential RNG., def LinearCongruential_Initialize(a, c, m, X0):, r""", , Hiva-Network.Com
Page 732 :
B.8 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , 731, , This functional initializes a linear congruential, RNG state., This state is a list of four integers: [a, c, m, X], a,c,m are the parameters of the linear congruential, instantiation X is the current state of the PRNG., INPUT:, a − The coefficient, c − The offset, m − The modulus, X0 − The initial state, OUTPUT:, state − The initial internal state of the RNG, """, return [a,c,m,X0], def LinearCongruential_Generate(state):, r""", Generates a single linear congruential RNG output, and updates the state., INPUT:, state − an internal RNG state., OUTPUT:, X − a single output of the linear congruential RNG., """, a = state[0], c = state[1], m = state[2], X = state[3], X_next = (a*X + c) % m, state[3] = X_next, return X_next, , B.8 CHAPTER 9: PUBLIC-KEY CRYPTOGRAPHY AND RSA, Example 1: Using Sage we can simulate an RSA encryption and decryption., sage: # randomly select some prime numbers, sage: p = random_prime(1000); p, 191
Page 733 :
732, , APPENDIX B / SAGE EXAMPLES, , sage: q = random_prime(1000); q, 601, sage: # compute the modulus, sage: N = p*q, sage: R = IntegerModRing(N), sage: phi_N = (p−1)*(q−1), sage: # we can choose the encrypt key to be anything, sage: # relatively prime to phi_N, sage: e = 17, sage: gcd(d, phi_N), 1, sage: # the decrypt key is the multiplicative, inverse, sage: # of d mod phi_N, sage: d = xgcd(d, phi_N)[1] % phi_N, sage: d, 60353, sage: # Now we will encrypt/decrypt some random 7, digit numbers, sage:, 97, sage:, sage:, 46685, sage:, sage:, 97, , P = randint(1,127); P, , sage:, 46, sage:, sage:, 75843, sage:, sage:, 46, , P = randint(1,127); P, , sage:, 3, sage:, sage:, 288, sage:, sage:, 3, , P = randint(1,127); P, , # encrypt, C = R(P)^e; C, # decrypt, R(C)^d, , # encrypt, C = R(P)^e; C, # decrypt, R(C)^d, , # encrypt, C = R(P)^e; C, # decrypt, R(C)^d, , Also, Sage can just as easily do much larger numbers:, sage: p = random_prime(1000000000); p
Page 734 :
B.8 / PUBLIC-KEY CRYPTOGRAPHY AND RSA, , 733, , 114750751, sage: q = random_prime(1000000000); q, 8916569, sage: N = p*q, sage: R = IntegerModRing(N), sage: phi_N = (p−1)*(q−1), sage: e = 2^16 + 1, sage: d = xgcd(e, phi_N)[1] % phi_N, sage: d, 237150735093473, sage: P = randint(1,1000000); P, 955802, sage: C = R(P)^e, sage: R(C)^d, 955802, Example 2: In Sage, we can also see an example of RSA signing/verifying., sage:, 1601, sage:, 4073, sage:, sage:, sage:, sage:, sage:, 1, sage:, sage:, sage:, sage:, , p = random_prime(10000); p, q = random_prime(10000); q, N = p*q, R = IntegerModRing(N), phi_N = (p−1)*(q−1), e = 47, gcd(e, phi_N), d, #, #, #, , = xgcd(e,phi_N)[1] % phi_N, Now by exponentiating with the private key, we are effectively signing the data, a few examples of this, , sage: to_sign = randint(2,2^10); to_sign, 650, sage: # the signature is checked by exponentiating, sage: # and checking vs the to_sign value, sage: signed = R(to_sign)^d; signed, 2910116, sage: to_sign == signed^e, True, sage: to_sign = randint(2,2^10); to_sign, 362, sage: signed = R(to_sign)^d; signed, 546132, sage: to_sign == signed^e, True
Page 735 :
734, , APPENDIX B / SAGE EXAMPLES, , sage: # we can also see what happens if we try to, verify a bad signature, sage: to_sign = randint(2,2^10); to_sign, 605, sage: signed = R(to_sign)^d; signed, 1967793, sage: bad_signature = signed − randint(2,100), sage: to_sign == bad_signature^e, False, , B.9 CHAPTER 10: OTHER PUBLIC-KEY CRYPTOSYSTEMS, Example 1: Here is an example of Alice and Bob performing a Diffie–Hellman, Key Exchange done in Sage:, sage: # Alice and Bob agree on the domain, parameters:, sage: p = 619, sage: F = GF(p), sage: g = F(2), sage: # Alice picks a random value x in 1 . . . 618, sage: x = randint(1,618); x, 571, sage: # Alice computes X = g^x and sends this to Bob, sage: X = g^571; X, 591, sage: # Bob picks a random value y in 1 . . . 618, sage: y = randint(1,618);y, 356, sage: # Bob computes Y = g^y and sends this to Alice, sage: Y = g^y; Y, 199, sage: # Alice computes Y^x, sage: Y^x, 563, sage: # Bob computes X^y, sage: X^y, 563, sage: # Alice and Bob now share a secret value, Example 2: In reality to prevent what is known as small subgroup attacks, the, prime p is chosen so that p - 2q + 1 where p is a prime as well., sage: q = 761, sage: p = 2*q + 1, sage: is_prime(q), True
Page 736 :
B.9 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , sage:, True, sage:, sage:, sage:, 1, sage:, sage:, sage:, 312, sage:, sage:, 26, sage:, sage:, 24, sage:, sage:, 1304, sage:, sage:, 541, sage:, sage:, 541, sage:, , 735, , is_prime(p), F = GF(p), g = F(3), g^q, # note that g^q = 1 implies g is of order q, # Alice picks a random value x in 2 . . . q−1, x = randint(2,q−1); x, # Alice computes X = g^x and sends it to Bob, X = g^x; X, # Bob computes a random value y in 2 . . . q−1, y = randint(2,q−1); y, # Bob computes Y = g^y and sends it to Alice, Y = g^y; Y, # Alice computes Y^x, Y^x, # Bob computes X^y, X^y, # Alice and Bob now share the secret value 541, , Example 3: Sage has a significant amount of support for elliptic curves. This, functionality can be very useful when learning, because it allows you to easily, calculate things and get the big picture. Doing the examples by hand may, cause you to get mired in the details. First you instantiate an elliptic curve,, by specifying the field that it is over, and the coefficients of the defining, Weierstrass equation. For this purpose, we write the Weierstrass equation as, y2 + a1xy + a3y = x3 + a2x2 + a4x + a6, Then the Sage function EllipticCurve(R, [a1, a2, a3, a4, a6]) creates the elliptic, curve over the ring R., sage: E = EllipticCurve(GF(17), [1,2,3,4,5]), sage: E, Elliptic Curve defined by y^2 + x*y + 3*y = x^3 +, 2*x^2 + 4*x + 5 over Finite Field of size 17, sage: E = EllipticCurve(GF(29), [0,0,0,1,1]), sage: E, Elliptic Curve defined by y^2 = x^3 + x + 1 over, Finite Field of size 29
Page 737 :
736, , APPENDIX B / SAGE EXAMPLES, , sage: E = EllipticCurve(GF(127), [0,0,0,2,17]), sage: E, Elliptic Curve defined by y^2 = x^3 + 2*x + 17 over, Finite Field of size 127, sage: F.<theta> = GF(2^10), sage: E = EllipticCurve(F, [1,0,0,1,0]), sage: E, Elliptic Curve defined by y^2 + x*y = x^3 + x over, Finite Field in theta of size 2^10, Example 4: Koblitz curves. A Koblitz curve is an elliptic curve over a binary, field defined by an equation of the form, y2 + xy = x3 + ax2 + 1, where a = 0 or 1. FIPS 186-3 recommends a number of Koblitz curves for use, with the Digital Signature Standard (DSS). Here we give an example of a curve, of similar form to the Koblitz curves:, sage: F.<theta> = GF(2^17), sage: E = EllipticCurve(F,[1,0,0,theta,1]), sage: E, Elliptic Curve defined by y^2 + y = x^3 + theta*, x^2 = 1 over Finite Field in theta of size 2^17, Example 5: Sage can even easily instantiate curves of cryptographic sizes, like, K163, which is one of the FIPS 186-3 curves., sage: F.<theta> = GF(2^163), sage: E = EllipticCurve(F, [1,0,0,1,1]), sage: E, Elliptic Curve defined by y^2 + x*y = x^3 + x^2 + 1, over Finite Field in theta of size 2^163, However, you should be careful that when instantiating a curve of cryptographic, sizes, some of the functions on the curve object will not work because they, require exponential time to run. While you can compute some things with, these objects, it is best to leave your experimentation to the smaller sized, curves., You can calculate some values of the curve, such as the number of points:, sage: E = EllipticCurve(GF(107), [0,0,0,1,0]), sage: E.order(), 108, You can also determine the generators of a curve:, sage: E = EllipticCurve(GF(101), [0,0,0,1,0]), sage: E.gens(), ((7 : 42 : 1), (36 : 38 : 1))
Page 738 :
B.9 / OTHER PUBLIC-KEY CRYPTOSYSTEMS, , 737, , Note that this output is printed (x : y : z). This is a minor technical consideration, because Sage stores points in what is known as “projective coordinates.” The, precise meaning is not important, because for non-infinite points the value z will, always be 1 and the first two values in a coordinate will be the x and y coordinates,, exactly as you would expect. This representation is useful because it allows the, point at infinity to be specified as a point with the z coordinate equal to 0:, sage: E(0), (0 : 1 : 0), This shows how you can recognize a point at infinity as well as specify it. If you, want to get the x and y coordinates out of a point on the curve, you can do so, as follows:, sage: P = E.random_point(); P, (62 : 38 : 1), sage: (x,y) = P.xy(); (x,y), (62, 38), You can specify a point on the curve by casting an ordered pair to the curve as:, sage: P = E((62,−38)); P, (62 : 63 : 1), Now that you can find the generators on a curve and specify points you can, experiment with these points and do arithmetic as well. Continuing to use E, as the curve instantiated in the previous example, we can set G1 and G2 to the, generators:, sage: (G1, G2) = E.gens(), sage: P = E.random_point(); P, (49 : 29 : 1), You can compute the sum of two points as in the following examples:, sage:, (69 :, sage:, (40 :, sage:, (84 :, , G1 + G2 + P, 96 : 1), G1 + P, 62 : 1), P + P + G2, 25 : 1), , You can compute the inverse of a point using the unary minus ( -) operator:, sage: −P, (49 : 72 : 1), sage: −G1, (7 : 59 : 1), You can also compute repeated point addition (adding a point to itself many, times) with the * operator:, sage: 13*G1, (72 : 23 : 1)
Page 739 :
738, , APPENDIX B / SAGE EXAMPLES, , sage: 2*G2, (9 : 58 : 1), sage: 88*P, (87 : 75 : 1), And for curves over small finite fields you can also compute the order (discrete, log of the point at infinity with respect to that point)., sage: G1.order(), 10, sage: G2.order(), 10, sage: P.order(), 10, Example 6: Using the Sage elliptic curve functionality to perform a simulated, elliptic curve Diffie–Hellman (ECDH) key exchange., sage:, sage:, sage:, sage:, (94 :, sage:, 122, , #, F, E, G, 6, q, , calculate domain parameters, = GF(127), = EllipticCurve(F, [0, 0, 0, 3, 4]), = E.gen(0); G, : 1), = E.order(); q, , sage: # Alice computes a secret value x in, 2 . . . q−1, sage: x = randint(2,q−1); x, 33, sage: # Alice computes a public value X = x*G, sage: X = x*G; X, (55 : 89 : 1), sage: # Bob computes a secret value y in 2 . . . q−1, sage: y = randint(2,q−1); y, 55, sage: # Bob computes a public value Y = y*G, sage: Y = y*G; Y, (84 : 39 : 1), sage: # Alice computes the shared value, sage: x*Y, (91 : 105 : 1), sage: # Bob computes the shared value, sage: y*X, (91 : 105 : 1)
Page 740 :
B.10 / CRYPTOGRAPHIC HASH FUNCTIONS, , 739, , However, in practice most curves that are used have a prime order:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, sage:, (23 :, sage:, sage:, (23 :, , # Calculate the domain parameters, F = GF(101), E = EllipticCurve(F, [0, 0, 0, 25, 7]), G = E((97,34)), q = E.order(), # Alice computes a secret values x in 2 . . . q−1, x = randint(2,q−1), # Alice computes a public value X = x*G, X = x*G, # Bob computes a secret value y in 2 . . . q−1, y = randint(2,q−1), # Bob computes a public value Y = y*G, Y = y*G, # Alice computes the shared secret value, x*Y, 15 : 1), # Bob computes the shared secret value, y*X, 15 : 1), , B.10 CHAPTER 11: CRYPTOGRAPHIC HASH FUNCTIONS, Example 1: The following is an example of the MASH hash function in Sage., MASH is a function based on the use of modular arithmetic. It involves use, of an RSA-like modulus M, whose bit length affects the security. M should be, difficult to factor, and for M of unknown factorization, the security is based in, part on the difficulty of extracting modular roots. M also determines the block, size for processing messages. In essence, MASH is defined as:, Hi = ((xi ⊕ Hi - 1)2 OR Hi - 1)(mod M), where, A = 0xFF00 c 00, Hi - 1 = the largest prime less than M, xi = the ith digit of the base M expansion of input n. That is, we express n, as a number of base M. Thus:, n = x0 + x1M + x2M2 + c, The following is an example of the MASH hash function in Sage., #, # This function generates a mash modulus, # takes a bit length, and returns a Mash, # modulus l or l−1 bits long (if n is odd), , Hiva-Network.Com
Page 741 :
740, , APPENDIX B / SAGE EXAMPLES, , # returns p, q, and the product N, #, def generate_mash_modulus(l):, m = l.quo_rem(2)[0], p = 1, while (p < 2^(m−1)):, p = random_prime(2^m), q = 1, while (q < 2^(m−1)):, q = random_prime(2^m), N = p*q, return (N, p, q), #, # Mash Hash, # the value n is the data to be hashed., # the value N is the modulus, # Returns the hash value., #, def MASH(n, N):, H = previous_prime(N), q = n, while (0 != q):, (q, a) = q.quo_rem(N), H = ((H+a)^2 + H) % N, return H, The output of these functions running;, sage: data = ZZ(randint(1,2^1000)), sage: (N, p, q) = generate_mash_modulus(20), sage: MASH(data, N), 220874, sage: (N, p, q) = generate_mash_modulus(50), sage: MASH(data, N), 455794413217080, sage: (N, p, q) = generate_mash_modulus(100), sage: MASH(data, N), 268864504538508517754648285037, sage: data = ZZ(randint(1,2^1000)), sage: MASH(data, N), 236862581074736881919296071248, sage: data = ZZ(randint(1,2^1000)), sage: MASH(data, N), 395463068716770866931052945515
Page 742 :
B.11 / DIGITAL SIGNATURES, , B.11 CHAPTER 13: DIGITAL SIGNATURES, Example 1: Using Sage, we can perform a DSA sign and verify:, sage: # First we generate the domain parameters, sage: # Generate a 16 bit prime q, sage: q = 1;, sage: while (q < 2^15): q = random_prime(2^16), . . . .:, sage: q, 42697, sage: # Generate a 64 bit p, such that q divides, (p−1), sage: p = 1, sage: while (not is_prime(p)):, . . . .: p = (2^48 + randint(1,2^46)*2)*q + 1, . . . .:, sage: p, 12797003281321319017, sage: # Generate h and g, sage: h = randint(2,p−2), sage: h, 5751574539220326847, sage: F = GF(p), sage: g = F(h)^((p−1)/q), sage: g, 9670562682258945855, sage: # Generate a user public / private key, sage: # private key, sage: x = randint(2,q−1), sage: x, 20499, sage: # public key, sage: y = F(g)^x, sage: y, 7955052828197610751, sage: # Sign and verify a random value, sage: H = randint(2,p−1), sage: # Signing, sage: # random blinding value, sage: k = randint(2,q−1), sage: r = F(g)^k % q, sage: r = F(g)^k, sage: r = r.lift() % q, sage: r, 6805, sage: kinv = xgcd(k,q)[1] % q, , 741
Page 743 :
742, , APPENDIX B / SAGE EXAMPLES, , sage: s = kinv*(H + x*r) % q, sage: s, 26026, sage:, sage:, 12250, sage:, 6694, sage:, 16706, sage:, sage:, sage:, 6805, sage:, True, , # Verifying, w = xgcd(s,q)[1]; w, , sage:, sage:, sage:, sage:, sage:, sage:, 3284, sage:, sage:, sage:, 2330, , #, H, k, r, r, r, , sage:, sage:, 4343, sage:, 32191, sage:, 1614, sage:, sage:, sage:, 3284, sage:, True, , # Verifying, w = xgcd(s,q)[1]; w, , u1 = H*w % q; u1, u2 = r*w % q; u2, v = F(g)^u1 * F(y)^u2, v = v.lift() % q, v, v == r, Sign and verify another random value, = randint(2,p−1), = randint(2,q−1), = F(g)^k, = r.lift() % q, , kinv = xgcd(k,q)[1] % q, s = kinv*(H + x*r) % q, s, , u1 = H*w % q; u1, u2 = r*w % q; u2, v = F(g)^u1 * F(y)^u2, v = v.lift() % q, v, v == r, , Example 2: The following functions implement DSA domain parameter, generation, key generation, and DSA Signing:, #, # Generates a 16 bit q and 64 bit p, both prime, # such that q divides p−1, #
Page 744 :
B.11 / DIGITAL SIGNATURES, , def DSA_generate_domain_parameters():, g = 1, while (1 == g):, # first find a q, q = 1, while (q < 2^15): q = random_prime(2^16), # next find a p, p = 1, while (not is_prime(p)):, p = (2^47 + randint(1,2^45)*2)*q + 1, F = GF(p), h = randint(2,p−1), g = (F(h)^((p−1)/q)).lift(), return (p, q, g), #, # Generates a users private and public key, # given domain parameters p, q, and g, #, def DSA_generate_keypair(p, q, g):, x = randint(2,q−1), F = GF(p), y = F(g)^x, y = y.lift(), return (x,y), #, # Given domain parameters p, q and g, # as well as a secret key x, # and a hash value H, # this performs the DSA signing algorithm, #, def DSA_sign(p, q, g, x, H):, k = randint(2,q−1), F = GF(p), r = F(g)^k, r = r.lift() % q, kinv = xgcd(k,q)[1] % q, s = kinv*(H + x*r) % q, return (r, s), , 743
Page 747 :
746, , REFERENCES, , DAVI89, DAWS96, DENN81, DENN82, DENN83, DIFF76a, DIFF76b, DIFF77, DIFF79, DIFF88, DIMI07, DOBB96, ELGA84, ELGA85, ENIS09, FEIS73, FEIS75, FERN99, FLUH00, FLUH01, FORD95, FRAN07, GARD77, GEOR12, , GOLD88, GONG92, GONG93, GOOD11, , Davies, D., and Price, W. Security for Computer Networks. New York: Wiley, 1989., Dawson, E., and Nielsen, L. “Automated Cryptoanalysis of XOR Plaintext Strings.”, Cryptologia, April 1996., Denning, D., and Sacco, G. “Timestamps in Key Distribution Protocols.” Communications, of the ACM, August 1981., Denning, D. Cryptography and Data Security. Reading, MA: Addison-Wesley, 1982., Denning, D. “Protecting Public Keys and Signature Keys.” Computer, February 1983., Diffie, W., and Hellman, M. “New Directions in Cryptography.” Proceedings of the, AFIPS National Computer Conference, June 1976., Diffie, W., and Hellman, M. “Multiuser Cryptographic Techniques.” IEEE Transactions, on Information Theory, November 1976., Diffie, W., and Hellman, M. “Exhaustive Cryptanalysis of the NBS Data Encryption, Standard.” Computer, June 1977., Diffie, W., and Hellman, M. “Privacy and Authentication: An Introduction to Cryptography.” Proceedings of the IEEE, March 1979., Diffie, W. “The First Ten Years of Public-Key Cryptography.” Proceedings of the IEEE,, May 1988., Dimitriadis, C. “Analyzing the Security of Internet Banking Authentication Mechanisms.”, Information Systems Control Journal, Vol. 3, 2007., Dobbertin, H. “The Status of MD5 After a Recent Attack.” CryptoBytes, Summer 1996., Elgamal, T. “A Public Key Cryptosystem and a Signature Scheme Based on Discrete, Logarithms.” Proceedings, Crypto 84, 1984., Elgamal, T. “A Public Key Cryptosystem and a Signature Scheme Based on Discrete, Logarithms.” IEEE Transactions on Information Theory, July 1985., European Network and Information Security Agency. Cloud Computing: Benefits,, Risks and Recommendations for Information Security. ENISA Report, November 2009., Feistel, H. “Cryptography and Computer Privacy.” Scientific American, May 1973., Feistel, H.; Notz, W.; and Smith, J. “Some Cryptographic Techniques for Machine-toMachine Data Communications.” Proceedings of the IEEE, November 1975., Fernandes, A. “Elliptic Curve Cryptography.” Dr. Dobb’s Journal, December 1999., Fluhrer, S., and McGrew, D. “Statistical Analysis of the Alleged RC4 Key Stream, Generator.” Proceedings, Fast Software Encryption 2000, 2000., Fluhrer, S.; Mantin, I.; and Shamir, A. “Weakness in the Key Scheduling Algorithm of, RC4.” Proceedings, Workshop in Selected Areas of Cryptography, 2001., Ford, W. “Advances in Public-Key Certificate Standards.” ACM SIGSAC Review,, July 1995., Frankel, S., et al. Establishing Wireless Robust Security Networks: A Guide to IEEE, 802.11i. NIST Special Publication SP 800-97, February 2007., Gardner, M. “A New Kind of Cipher That Would Take Millions of Years to Break.”, Scientific American, August 1977., Georgiev, M., et al. “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.” ACM Conference on Computer and Communications, Security, 2012., Goldwasser, S.; Micali, S.; and Rivest, R. “A Digital Signature Scheme Secure Against, Adaptive Chosen-Message Attacks.” SIAM Journal on Computing, April 1988., Gong, L. “A Security Risk of Depending on Synchronized Clocks.” Operating Systems, Review, January 1992., Gong, L. “Variations on the Themes of Message Freshness and Replay.” Proceedings,, IEEE Computer Security Foundations Workshop, June 1993., Goodin, D. “Hackers Break SSL Encryption Used by Millions of Sites.” The Register,, September 19, 2011.
Page 748 :
REFERENCES, GOOD12, GUTT06, HACI02, , HELL79, HEVI99, , HILT06, HOWA03, HUIT98, IANS90, INTE12, IWAT03, JAIN91, JAKO98, , JANS11, JOHN05, JONE82, JUEN85, JONS02, JUEN87, JURI97, KALI95, KALI96a, KALI96b, KALI01, , 747, , Goodin, D. “Crack in Internet’s Foundation of Trust Allows HTTPS Session Hijacking.”, Ars Technica, September 13, 2012., Gutterman, Z.; Pinkas, B.; and Reinman, T. “Analysis of the Linux Random Number, Generator.” Proceedings, 2006 IEEE Symposium on Security and Privacy, 2006., Hacigumus, H., et al. “Executing SQL over Encrypted Data in the Database-ServiceProvider Model.” Proceedings, 2002 ACM SIGMOD International Conference on, Management of Data, 2002., Hellman, M. “The Mathematics of Public-Key Cryptography.” Scientific American,, August 1970., Hevia, A., and Kiwi, M. “Strength of Two Data Encryption Standard Implementations Under Timing Attacks.” ACM Transactions on Information and System Security,, November 1999., Hiltgen, A.; Kramp, T.; and Wiegold, T. “Secure Internet Banking Authentication.”, IEEE Security and Privacy, Vol. 4, No. 2, 2006., Howard, M.; Pincus, J.; and Wing, J. “Measuring Relative Attack Surfaces.” Proceedings,, Workshop on Advanced Developments in Software and Systems Security, 2003., Huitema, C. IPv6: The New Internet Protocol. Upper Saddle River, NJ: Prentice Hall,, 1998., I’Anson, C., and Mitchell, C. “Security Defects in CCITT Recommendation X.509—The, Directory Authentication Framework.” Computer Communications Review, April 1990., Intel Corp. Intel® Digital Random Number Generator (DRNG) Software Implementation Guide. August 7, 2012., Iwata, T., and Kurosawa, K. “OMAC: One-Key CBC MAC.” Proceedings, Fast Software, Encryption, FSE ’03, 2003., Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. New York: Wiley, 1991., Jakobsson, M.; Shriver, E.; Hillyer, B.; and Juels, A. “A Practical Secure Physical Random, Bit Generator.” Proceedings of the Fifth ACM Conference on Computer and Communications Security, November 1998., Jansen, W., and Grance, T. Guidelines on Security and Privacy in Public Cloud, Computing. NIST Special Publication 800-144, January 2011., Johnson, D. “Hash Functions and Pseudorandomness.” Proceedings, First NIST, Cryptographic Hash Workshop, 2005., Jones, R. “Some Techniques for Handling Encipherment Keys.” ICL Technical Journal,, November 1982., Jueneman, R.; Matyas, S.; and Meyer, C. “Message Authentication.” IEEE Communications Magazine, September 1958., Jonsson, J. “On the Security of CTR + CBC-MAC.” Proceedings of Selected Areas in, Cryptography – SAC 2002, 2002., Jueneman, R. “Electronic Document Authentication.” IEEE Network Magazine,, April 1987., Jurisic, A., and Menezes, A. “Elliptic Curves and Cryptography.” Dr. Dobb’s Journal,, April 1997., Kaliski, B., and Robshaw, M. “The Secure Use of RSA.” CryptoBytes, Autumn 1995., Kaliski, B., and Robshaw, M. “Multiple Encryption: Weighing Security and Performance.”, Dr. Dobb’s Journal, January 1996., Kaliski, B. “Timing Attacks on Cryptosystems.” RSA Laboratories Bulletin, January, 1996. http://www.rsasecurity.com/rsalabs., Kaliski, B. “RSA Digital Signatures.” Dr. Dobb’s Journal, May 2001.
Page 750 :
REFERENCES, MA10, MANA11, MANT01, MATY91a, MATY91b, MAUW05, MCGR04, MCGR05, MECH14, , MENE97, MERK79, MERK81, MERK89, MEYE88, MEYE13, , MICA91, MILL75, MILL88, , MITC90, MITC92, MOOR01, , MYER91, NCAE13, NEED78, , 749, , Ma, D., and Tsudik, G. “Security and Privacy in Emerging Wireless Networks.” IEEE, Wireless Communications, October 2010., Manadhata, P., and Wing, J. “An Attack Surface Metric.” IEEE Transactions on Software, Engineering, Vol. 37, No. 3, 2011., Mantin, I., Shamir, A. “A Practical Attack on Broadcast RC4.” Proceedings, Fast, Software Encryption, 2001., Matyas, S. “Key Handling with Control Vectors.” IBM Systems Journal, No. 2, 1991., Matyas, S.; Le, A.; and Abrahan, D. “A Key Management Scheme Based on Control, Vectors.” IBM Systems Journal, No. 2, 1991., Mauw, S., and Oostdijk, M. “Foundations of Attack Trees.” International Conference on, Information Security and Cryptology, 2005., McGrew, D., and Viega, J. “The Security and Performance of the Galois/Counter Mode, (GCM) of Operation.” Proceedings, Indocrypt 2004., McGrew, D., and Viega, J. “Flexible and Efficient Message Authentication in Hardware, and Software.” 2005. Available at http://www.cryptobarn.com/gcm/gcm-paper.pdf., Mechalas, J. Intel® Digital Random Number Generator (DRNG) Software Implementation, Guide. Intel Developer Zone, May 15, 2014. https://software.intel.com/en-us/articles/, intel-digital-random-number-generator-drng-software-implementation-guide., Menezes, A.; Oorshcot, P.; and Vanstone, S. Handbook of Applied Cryptography. Boca, Raton, FL: CRC Press, 1997. Available at http://cacr.uwaterloo.ca/hac/index.html., Merkle, R. Secrecy, Authentication, and Public Key Systems. Ph.D. Thesis, Stanford, University, June 1979., Merkle, R., and Hellman, M. “On the Security of Multiple Encryption.” Communications, of the ACM, July 1981., Merkle, R. “One Way Hash Functions and DES.” Proceedings, CRYPTO ’89, 1989;, published by Springer-Verlag., Meyer, C., and Schilling, M. “Secure Program Load with Modification Detection Code.”, Proceedings, SECURICOM 88, 1988., Meyer, C.; Schwenk, J.; and Gortz, H. “Lessons Learned From Previous SSL/TLS, Attacks: A Brief Chronology of Attacks And Weaknesses.” Cryptology ePrint Archive,, 2013. http://eprint.iacr.org/2013/., Micali, S., and Schnorr, C. “Efficient, Perfect Polynomial Random Number Generators.”, Journal of Cryptology, January 1991., Miller, G. “Riemann’s Hypothesis and Tests for Primality.” Proceedings of the Seventh, Annual ACM Symposium on the Theory of Computing, May 1975., Miller, S.; Neuman, B.; Schiller, J.; and Saltzer, J. “Kerberos Authentication and Authorization System.” Section E.2.1, Project Athena Technical Plan, M.I.T. Project Athena,, Cambridge, MA, 27 October 1988., Mitchell, C.; Walker, M.; and Rush, D. “CCITT/ISO Standards for Secure Message, Handling.” IEEE Journal on Selected Areas in Communications, May 1989., Mitchell, C.; Piper, F. ; and Wild, P. “Digital Signatures.” in [SIMM92]., Moore, A.; Ellison, R.; and Linger, R. “Attack Modeling for Information Security and, Survivability.” Carnegie–Mellon University Technical Note CMU/SEI-2001-TN-001,, March 2001., Myers, L. Spycomm: Covert Communication Techniques of the Underground. Boulder,, CO: Paladin Press, 1991., National Centers of Academic Excellence in Information Assurance/Cyber Defense., NCAE IA/CD Knowledge Units. June 2013., Needham, R., and Schroeder, M. “Using Encryption for Authentication in Large, Networks of Computers.” Communications of the ACM, December 1978.
Page 753 :
752, , REFERENCES, , WEBS86, WIEN90, WOO92a, WOO92b, WOOD10, YUVA79, XU10, , Webster, A., and Tavares, S. “On the Design of S-Boxes.” Proceedings, Crypto ’85, 1985;, published by Springer-Verlag., Wiener, M. “Cryptanalysis of Short RSA Secret Exponents.” IEEE Transactions on, Information Theory, Vol. 36, No. 3, 1990., Woo, T., and Lam, S. “Authentication for Distributed Systems.” Computer, January 1992., Woo, T., and Lam, S. “ ‘Authentication’ Revisited.” Computer, April 1992., Wood, T., et al. “Disaster Recovery as a Cloud Service: Economic Benefits & Deployment Challenges.” Proceedings, USENIX HotCloud ’10, 2010., Yuval, G. “How to Swindle Rabin.” Cryptologia, July 1979., Xu, L. Securing the Enterprise with Intel AES-NI. Intel White Paper, September 2010.
Page 754 :
CREDITS, Page 21: Definition of Computer Security from An Introduction, to Computer Security: The NIST Handbook by Guttman, B. and, Roback, E.A. Published by DIANE Publishing, © 1995., Page 27: From RFC 4949 by Shirey, R. published by The IETF, Trust, © 2007., Page 29–30: Excerpt from Data Communication Networks:, Open Systems Interconnection (OSI); Security, Structure and, Applications, Permission provided by International Telecommunication Union (ITU)., Page 30: Excerpt from Data Communication Networks: Open, Systems Interconnection (OSI); Security, Structure and Applications, Permission provided by International Telecommunication, Union (ITU)., Page 32–33: Excerpt from Data Communication Networks: Open, Systems Interconnection (OSI); Security, Structure and Applications, Permission provided by International Telecommunication, Union (ITU)., Page 33: Recommendation X.800 - Data Communication Networks: Open Systems Interconnection (OSI); Security, Structure, and Applications, Permission provided by International Telecommunication Union., Page 111: Excerpt from The Silent World of Nicholas Quinn by, Colin Dexter, published by Pan Macmillan, © 2011., Page 239: Draft NIST Special Publication 800-38G, U.S. Department of Commerce., Page 285: NIST IR 7298, Revision 2, U.S. Department of, Commerce., Page 333: Draft NIST Special Publication 800-57, Part 1, Revision 4, U.S. Department of Commerce., Page 399: Data Authentication Algorithm Figure, William Stallings., Page 414: Basic Structure of Hash-Based PRNGs Figure, William, Stallings., , Page 471: Definition of Cryptoperiod from Recommendation, for Key Management – Part 1: General (Revision 3), NIST, Special Publication 800-57, U.S. Department of Commerce., Page 510: Federal Information Processing Standards Publication, Personal Identity Verification (PIV) of Federal Employees, and Contractors, U.S. Department of Commerce., Page 527: Terminology Related to IEEE 802.1X Table, William, Stallings., Page 530: Definition of Cloud Computing from The NIST Definition of Cloud Computing: Recommendations of the National, Institute of Standards and Technology, U.S. Department of, Commerce., Page 533: NIST Cloud Computing Reference Architecture:, Recommendations of the National Institute of Standards and, Technology, U.S. Department of Commerce., Page 534: NIST Cloud Computing Reference Architecture: Recommendations of the National Institute of Standards and Technology, U.S. Department of Commerce., Page 538–539: Guidelines on Security and Privacy in Public, Cloud Computing, U.S. Department of Commerce., Page 621: Excerpt from Multipurpose Internet Mail Extensions, (MIME) Part Two by Ned Freed and Nathaniel S. Borenstein,, published by Internet Engineering Task Force, © 1996., Page 626: Trustworthy Email, U.S. Department of Commerce., Page 632: Excerpt from Key words for use in RFCs to Indicate, Requirement Levels by S. Bradner, published by Internet Engineering Task Force, © 1997., Page 697: Quote from On War by Carl von Clausewitz edited, by Michael Howard and Peter Paret, published by Princeton, University Press, © 1989., Page 703–743: Provided by Dan Shumow., , 753
Page 755 :
INDEX, A, , Abelian groups, 144–145, 322–323, associative, 322, closure, 322, commutative, 322, elliptic curve, 323, identity element, 322, inverse element, 322, Absorbing phase, 367, 368, Access control, 30–32, 528, 584, 591–592,, 596, 601, Access point (AP), 583, 584–585, 590, 592, Access requestor (AR), 520, Accidental association, 583, Accountability, 23, Active attacks, 27–29, denial of service, 29, masquerade, 28, modification of messages, 28, replay, 28, Ad hoc networks, 583, Adaptive chosen message attack, 422, Adaptive Proportion Test, 276, Addition, 145, 146, 164, algebraic description of, 325, geometric description of, 323–325, Additive inverse, 56, AddRoundKey, 174, 177, 180, 198–200, forward add round key, transformation, 189, inputs for single AES round, 190, inverse add round key transformation,, 189, Administrative management domain, (ADMD), 615, 651–652, Advanced Encryption Standard (AES),, 119, 129, 142, 160, 172, 724–729, AddRoundKey and InvMixColumns,, 198–199, avalanche effect, 194–197, byte-level operations, 180, data structures, 176, detailed structure, 177–179, AddRoundKey, 177, MixColumns, 177, ShiftRows, 177, substitute bytes, 177, encryption, and decryption, 178, process, 175, round, 179, equivalent inverse cipher, 197–199, example, 193–197, vs. FPE, 231, general structure, 174–177, State, 174, implementation, 197–201, 8-bit processor, 199–200, 32-bit processor, 200–201, inputs for, 190, InvShiftRows and InvSubByte, 198, key expansion, 190–193, parameters, 177, row and column operations, 186, State array, 174, transformation functions (See, Transformation functions, AES), AH. See Authentication Header (AH), Alert protocol, 554–555, Algorithm, decryption, 288, design, 257–258, asymmetric ciphers, 258, cryptographic algorithms, 257–258, , 754, , hash functions, 258, message authentication codes, 258, purpose-built algorithms, 257, symmetric block ciphers, 258, encryption, 286, negotiation, 571, ANSI X9.17 PRNG, 263–264, input, 263, keys, 263, output, 264, Anti-replay service, 675–676, receiver, 676, replay attack, 675, sender, 676, AP. See Access point (AP), AR. See Access requestor (AR), Arbitrary reversible substitution cipher,, 122, Associative group, 143, 322, Associative laws, 56, Associativity of multiplication, 145, Asymmetric card authentication key, 512, Asymmetric cipher, 258, 334–336, Asymmetric encryption, 20, keys, 288, PKI, 285, public key certificate, 285, public key cryptographic algorithm,, 285, terminology related to, 285, Attack surfaces, 37–38, Attack trees, 38–40, Authenticated encryption (AE), 402–408, CMAC, 402–405, GCM, 405–408, authentication and encryption, functions, 406, message authentication code, 407, Authentication, data origin, 30, ESP, 681, exchange, 33, IEEE 802.11i wireless LAN security,, 596, 601–603, IKE key determination, 687, payload, 691, peer entity, 29, 30, protocols, 20, public-key cryptography, 290, 291, server, 525, S/MIME, 628–630, Authentication Header (AH), 666, 669, Authentication service exchange, 496, Authenticator, 290, 383, 525, 527, 530, Authenticity, 23, Authenticity-related threats, 625, Authority key identifier, 466, Autokey system, 104, Automated key management, 684, Availability, 22, 24, Availability service, 32, Availability-related threats, 625, Avalanche effect, 194–197, DES, 131–133, , B, , Backward unpredictability, 256, Barrier security, 589, Base64 transfer encoding, 623, Basic service set (BSS), 590, 592, BIC. See Bit independence criterion, (BIC), Big-endian format, 358, Bijection, 71, Binary curve, 325, , Binary operator, 53, Binary operator mod, 83, BIO, 513, BIO-A, 513, Birthday attack, 355, Birthday paradox, 351, Bit independence criterion (BIC), 136, 56-Bit keys, 134, Bit length, 238, 8-Bit processor, 199–200, 32-Bit processor, 200–201, Bitrate, 365, 366, Blinding, 306, Block cipher, 120–121, 713–717, advantage of, 268, CBC mode, 216–218, CFB mode, 218–220, CTR mode, 218, 222–224, encryption, 218, OFB mode, 218, 220–222, s-bit, 219, segments, 218, CTR mode, 218, 222–224, advantages of, 223–224, hardware efficiency, 223, preprocessing, 224, provable security, 224, random access, 224, simplicity, 224, software efficiency, 224, design principles, 135–137, BIC, 136, design of function F, 136–137, key schedule algorithm, 137, number of rounds, 136, SAC, 136, double DES, 208–210, ECB, 213–216, diffusion, 216, error propagation, 215, error recovery, 215, modes of operation, 213, overhead, 215, security, 216, FPE, 231–245, AES vs., 231, difficulties in designing an,, 232–233, Feistel structure for, 233–238, motivation, 231–232, NIST methods for, 238–245, notation in, 236, parameters in, 236, internals, 699, MAC on, 399–401, CMAC, 400–401, DAA, 399–400, modes of operation, 214, modes of use, 699, multiple encryption, 208–213, OFB mode, 218, 220–222, PRNGs, 261–267, ANSI X9.17 PRNG, 263–264, mechanisms, 262, NIST CTR_DRBG, 264–267, processes, 89, projects, 699, round, 699, symmetric, 258, triple DES, known-plaintext attack on, 212, with three keys, 213, with two keys, 210–213, TRNG, 274, tweakable, 225–226
Page 756 :
INDEX, XTS-AES mode, 224–231, ciphertext-stealing technique, 229, definition, 230, feedback characteristic of modes of, operation, 225, operation on sector, 229–231, operation on single block, 227–229, storage encryption requirements,, 226–227, tweakable block ciphers, 225–226, Block size, 126, Blum Blum Shub (BBS) generator,, 260–261, 729–730, Bring-your-own-device (BYOD) policy,, 587, Broad network access, 530–531, Brute-force approach, 253, Brute-force attacks, 89, 91, 255, 302, 350–353, birthday paradox, 351, collision resistant attacks, 351–353, cryptanalysis, 353–354, MAC, 393–394, preimage and second preimage, attacks, 351, BSS. See Basic service set (BSS), Business continuity and disaster, recovery, 543, BYOD policy. See Bring-your-owndevice (BYOD) policy, , C, , Caesar cipher, 92–94, 102–103, Canonical form, 625, Capacity, 367, Card authentication key, 513, Cardholder unique identifier (CHUID),, 511, 512, CBC mode. See Cipher block chaining, (CBC) mode, CBC-MAC/CMAC, 278, CCA. See Chosen ciphertext attack, (CCA), CCMP. See Counter Mode-CBC MAC, Protocol (CCMP), Certificate Association Data, 644, Certificate payload, 691, Certificate policies, 466, Certificate Request payload, 691, Certification authority (CA), forward certificates, 463, reverse certificates, 463, CFB mode. See Cipher feedback (CFB), mode, Change Cipher Spec protocol, 553, Character marking, 110, Character strings, 235–237, Chi step function, 372, 375–376, Chinese remainder theorem (CRT),, 71–73, 300, 705–706, bijection, 71, first assertion, 71–72, second assertion, 72, Chosen ciphertext attack (CCA), 90, 302,, 307–308, Chosen text attack, 90, Chosen-plaintext approach, 211, Chosen-plaintext attack, 90, CHUID. See Cardholder unique, identifier (CHUID), CIA triad, 22, accountability, 23, authenticity, 23, availability, 22, 24, confidentiality, 22, high level, 23, integrity, 22, 24, low level, 23, moderate level, 23, Cipher, 86, block (See Block cipher), , design principles, 135–137, design of function F, 136–137, key schedule algorithm, 137, number of rounds, 136, SAC, 136, Cipher block chaining (CBC) mode,, 216–218, 347, hash function based on, 354–355, Cipher feedback (CFB) mode, 218–220, CTR mode, 218, 222–224, encryption, 218, OFB mode, 218, 220–222, s-bit, 219, segments, 218, Cipher spec, 551, Cipher-Based Message Authentication, Code (CMAC), 400–405, Ciphertext, 86, 87, 287, plaintext transforming to, 89, Ciphertext only attack, 90, Ciphertext-stealing technique, 229, Claimant, 476, Classical encryption, 86–111, 710–713, Client write key, 551, Client write MAC secret, 551, Client/server authentication exchange, 498, Closure, 143, under multiplication, 145, Closure group, 322, Cloud auditor, 534, 535, Cloud broker, 534, 535, service aggregation, 535, service arbitrage, 535, service intermediation, 535, Cloud carrier, 534, 535, Cloud computing, 529–535, characteristics of, 530–532, broad network access, 530–531, measured service, 531, on-demand self-service, 531, rapid elasticity, 531, resource pooling, 531–532, context, 533, deployment models, community cloud, 532, hybrid cloud, 532, private cloud, 532, public cloud, 532, elements, 530–533, reference architecture, 534–535, cloud auditor, 534, 535, cloud broker, 534, 535, cloud carrier, 534, 535, cloud consumer, 534, cloud provider, 534, service models, IaaS, 532, PaaS, 532, SaaS, 532, Cloud consumer, 534, Cloud provider, 534, Cloud security, addressing, 544, risks and countermeasures, 535–537, abuse and nefarious use, 536, account or service hijacking, 537, data loss or leakage, 537, insecure interfaces and APIs, 536, malicious insiders, 536, shared technology issues, 536–537, unknown risk profile, 537, as service, 541–544, CMAC. See Cipher-Based Message, Authentication Code (CMAC), Coefficient set, 151, Collision, 348, Collision resistant, 349, attacks, 351–353, brute-force attacks, 351–353, Communications channel (CC), 40, , 755, , Community cloud, 532, Commutative, 144, Commutative group, 322, Commutative laws, 56, Commutative ring, 145, Commutativity of multiplication, 145, Complete mediation, 35, Composite number, 69, Composition, 370, Comprehensive email security, 625–627, Compression, function, 354, method, 551, S/MIME, 631–632, Computation resistance, MAC, 393, Computational aspects, 297–302, Computationally secure encryption, scheme, 91, Computer algebra system (CAS), 697, Computer security, availability, 22, 24, challenges, 25–26, confidentiality, data, 21, privacy, 21, definition of, 21, integrity, 22, 24, Conditioning algorithms, 273, Confidentiality, 21, 22, 24, 551, public-key cryptosystem, 289, S/MIME, 629–630, Confidentiality-related threats, 625, Configuration payload, 692, Confusion, 124–125, Congruences, properties of, 53, relation, 53, relation mod, 83–84, Congruent modulo n, 35, Connection confidentiality, 30, Connection integrity, recovery and, 30, selective-field, 30, Connection protocol, 574–578, channel mechanism, 574–575, close a channel, 575, data transfer, 575, open a new channel, 575, channel types, 575–576, direct-tcpip, 576, forwarded-tcpip, 576, session, 575, x11, 575, port forwarding, 576–578, Connectionless confidentiality, 30, Connectionless integrity, 30, selective-field, 30, Consistency, 255, Constant exponentiation time, 306, Constant polynomial, 151, Content types, 620–622, application type, 622, message type, 622, message/external-body subtype, 622, message/partial subtype, 622, message/rfc822 subtype, 622, multipart type, 621, multipart/alternative subtype, 621–622, multipart/digest subtype, 622, multipart/mixed subtype, 621, multipart/parallel subtype, 621, text type, 621, Content-Description header fields, 620, Content-ID header fields, 620, Content-Transfer-Encoding header, fields, 620, Content-Type header fields, 619, Conventional encryption, 86, 89, 289, attacking, 89, secure use of, 87
Page 757 :
756, , INDEX, , Cookie exchange, 686, Counter (CTR) mode, 218, 222–224, advantages of, 223–224, hardware efficiency, 223, preprocessing, 224, provable security, 224, random access, 224, simplicity, 224, software efficiency, 224, Counter Mode-CBC MAC Protocol, (CCMP), 608, CREATE_CHILD_SA exchange, 688, Credential, 476, Credential service provider (CSP), 476, CRT. See Chinese remainder theorem, (CRT), Cryptanalysis, 86, 353–354, and brute-force attack, 89–91, computationally secure, 91, types of attacks on encrypted, messages, 90, unconditionally secure, 91, compression function, 354, computational effort for, 333, MAC, 394, public-key, 294, RSA algorithm, 303, structure of secure hash code, 353, Cryptographic algorithms, 632–633, MUST, 632, and protocols, 20, asymmetric encryption, 20, authentication protocols, 20, data integrity algorithms, 20, symmetric encryption, 20, SHOULD, 632–633, Cryptographic checksum, 388, Cryptographic hash functions, 340–376,, 414, 739–741, applications of, 341–346, collision resistant, 349, digital signatures, 344–345, intrusion detection, 345, message authentication, 341–344, one-way password file, 345, preimage resistant, 349, PRF, 346, PRNG, 346, properties, relationship, 350, pseudorandomness, 350, requirements and security, 348–354, brute-force attacks, 350–353, collision, 348, cryptanalysis, 353–354, preimage, 348, second preimage resistant, 349, resistance properties, 350, virus detection, 345, Cryptographic suites, 692–694, encryption, 693, 694, message authentication, 693, 694, PRF, 693, 694, Cryptographic system, 86, Cryptographically secure pseudorandom, bit generator (CSPRBG), 260, Cryptography, 86, 89, and network security, block cipher projects, 699, case studies, 701, firewall projects, 701, hacking project, 698–699, laboratory exercises, 699, practical security assessments,, 700–701, programming projects, 700, reading/report assignments, 702, research projects, 699–700, sage computer algebra projects,, 697–698, writing assignments, 701–702, , number of keys used, 89, conventional encryption, 89, secret-key, 89, single-key, 89, symmetric key, 89, plaintext, 89, block cipher, 89, stream cipher, 89, transforming plaintext to ciphertext, 89, product systems, 89, Cryptology, 86, CSPRBG. See Cryptographically secure, pseudorandom bit generator, (CSPRBG), CTR mode. See Counter (CTR) mode, CTR_DRBG, 262, 264–267, Cubic equation, 323, 325, 328–329, Cyclic group, 145, , D, , DANE. See DNS-based authentication, of named entities (DANE), Data Authentication Algorithm (DAA),, 399–400, Data confidentiality, 21, 30, 31, CCMP, 608, TKIP, 607, Data encryption algorithm (DEA), 129, Data Encryption Standard (DES), 110,, 127, 129–131, 284, 713–717, avalanche effect, 131–133, DAA, 399–400, decryption, 131, double, 208–210, meet-in-the-middle attack, 210, reduction to single stage, 209–210, encryption, 130–131, example, 131–133, permuted input, 130, preoutput, 131, strength of, 134–135, nature of DES algorithm, 134–135, timing attacks, 135, use of 56-Bit keys, 134, subkey, 131, triple, known-plaintext attack on, 212, with three keys, 213, with two keys, 210–213, Data integrity, 20, 22, 30–32, Data loss prevention (DLP), 542–543, Data origin authentication, 30, Data protection in the cloud, 537–541, attributes, 540, entities, client, 539, data owner, 539, server, 540, user, 539, multi-instance model, 539, multi-tenant model, 539, primary key, 540, relation, 540, tuples, 540, Database, 639–640, distributed, 640, SAD (See Security association, database (SAD)), DEA. See Data encryption algorithm, (DEA), Deciphering, 86, Decryption, 86, 292, algorithm, 87, 288, DES, 131, elliptic curve, 331–333, Feistel cipher, 126, 127–129, FPE, 233–235, signature verification, 436, tables for substitution, 122, Defense in depth, 37, , Delete payload, 692, Denial of service (DoS), 29, 584, DES. See Data Encryption Standard, (DES), Deskewing algorithms, 273, Determinant, 99, Deterministic primality algorithm, 70, Device security, 587–589, DH. See Diffie-Hellman (DH), DHCP. See Dynamic Host Configuration, Protocol (DHCP), Diffie-Hellman (DH), key exchange, 314–315, algorithm, 315–316, 685–686, analog, 331, discrete logarithm, 315, example, 734, 738–739, key exchange protocols, 317, man-in-the-middle attack, 317–318, values, 687, Diffusion, 124–125, Digital random number generator, (DRNG), 276–279, hardware architecture, 277–278, CBC-MAC/CMAC, 278, Intel DRNG logical structure, 279, Intel processor chip, 277, logical structure, 278–279, Digital Signature Algorithm (DSA), 420,, 426–430, approach, 426–428, signing and verifying, 429, Digital signature key, 512, Digital signatures, 32, 286, 290, 292, 687,, 741–744, attacks and forgeries, adaptive chosen message attack, 422, directed chosen message attack, 422, existential forgery, 423, generic chosen message attack, 422, key-only attack, 422, known message attack, 422, selective forgery, 423, total break, 423, universal forgery, 423, cryptographic hash functions, 344–345, definition, 420, direct, 423–424, ECDSA, 430–433, Elgamal signature scheme, 424–425, essential elements, 421, NIST digital signature algorithm,, 426–430, properties, 421–422, requirements, 423, Schnorr signature scheme, 425–426, simplified examples, 345, Digrams, 96–98, Direct digital signature, 423–424, Directed chosen message attack, 422, Discrete logarithms, 73–78, 315, calculation of, 77–78, for modular arithmetic, 75–77, powers of integer, 73–75, Disk drives, 271–272, Distributed database, 640, Distribution system (DS), 590, 592, 594, Distributive laws, 56, 145, Divides, 47, 154, Divisibility, 47–48, Division algorithm, 48–49, Divisor, 47, 154, DNS Security Extensions (DNSSEC),, 625, 639–643, operation, 642, resource records for, 642–643, DNS-based authentication of named, entities (DANE), 625, 643–645, S/MIME, 645, SMTP, 645
Page 758 :
INDEX, TLSA record, 643–644, Certificate Association Data, 644, Matching Type field, 644, Selector field, 644, DNSSEC. See DNS Security Extensions, (DNSSEC), Domain Name System (DNS), 615, database, 639–640, distributed database, 640, domain name space, 639, elements, 639, name resolution, 641, name servers, 639, operation, 640–641, resolvers, 639, variable-depth hierarchy for names,, 639, Domain-Based Message Authentication,, Reporting and Conformance, (DMARC), 626–627, 654–658, functional flow, 657, identifier alignment, 654, on receiver side, 655–657, reports, 658, on sender side, 655, tag and value descriptions, 656, DomainKeys Identified Mail (DKIM),, 626, 648–654, deployment example, 651, email threats, 649–650, capabilities, 649–650, characteristics, 649, location, 650, functional flow, 651–654, strategy, 650–651, DoS. See Denial of service (DoS), Double encryption, 496, Dynamic biometrics, 476, Dynamic Host Configuration Protocol, (DHCP), 523, , E, , EAP. See Extensible Authentication, Protocol (EAP), EAP authenticator, 525, 530, EAP over LAN (EAPOL), -EAP packet, 529, packets, 528–529, body, 529, body length, 529, protocol version, 529, type, 529, -Start packet, 529, EAP peer, 525, 530, EAP-GPSK (EAP Generalized PreShared Key), 524, EAP-IKEv2, 524, EAPOL (EAP over LAN), 528, EAP-TLS (EAP Transport Layer, Security), 524, EAP-TTLS (EAP Tunneled TLS), 524, Ease of analysis, 127, Economy of mechanism, 34, EEPROM. See Electrically erasable, programmable ROM (EEPROM), Electrically erasable programmable, ROM (EEPROM), 509, Electronic codebook (ECB), 213–216, characteristic of, 214, diffusion, 216, error propagation, 215, error recovery, 215, modes of operation, 213, overhead, 215, security, 216, Electronic facial image, 512, Electronic mail security, 613–658, DANE, 625, 643–645, Secure/Multipurpose Internet Mail, Extension, 645, , Hiva-Network.Com, , Simple Mail Transfer Protocol, 645, TLSA record, 643–644, DKIM, 626, 648–654, email threats, 649–650, functional flow, 651–654, strategy, 650–651, DMARC, 654–658, functional flow, 657, identifier alignment, 654, on receiver side, 655–657, reports, 658, on sender side, 655, tag and value descriptions, 656, DNSSEC, 625, 639–643, operation, 642, resource records for, 642–643, email format, 617–625, MIME, 618–625, RFC 5322, 618, email threats and comprehensive, email security, 625–627, Internet mail architecture, 613–617, email components, 614–615, email protocols, 615–617, PGP, 638–639, S/MIME, 627–638, certificate processing, 637, cryptographic algorithms, 632–633, enhanced security services, 637–638, message content types, 632, messages, 633–637, operational description, 628–632, SPF, 626, 645–648, mechanisms, 647, modifiers, 647, operation, 648, on receiver side, 647–648, on sender side, 647, Elgamal cryptographic system, 318–321, Elgamal digital signature scheme,, 424–425, Elliptic curve, 323, Elliptic curve arithmetic, 321–330, abelian groups, 322–323, associative, 322, closure, 322, commutative, 322, elliptic curve, 323, identity element, 322, inverse element, 322, over GF(2m), 328–330, finite field, 328, points on, 328, over real numbers, 323–325, algebraic description of addition,, 325, example of, 324, geometric description of addition,, 323–325, Weierstrass equation, 323, over Zp, 325–328, binary curve, 325, points on, 326, prime curve, 325, Elliptic curve cryptography (ECC),, 321–322, 325, computational effort for cryptanalysis,, 333, Diffie-Hellman key exchange analog,, 331, encryption/decryption, 331–333, order, 331, PRNG on, 336, security of, 333–334, Elliptic Curve Digital Signature, Algorithm (ECDSA), generation and authentication,, 431–433, global domain parameters, 431, key generation, 431, , 757, , process involved in, 430, signing and verifying, 432, Email, compatibility, 630–631, components, 614–615, ADMD, 615, DNS, 615, MDA, 615, MHS, 614, MS, 615, MSA, 615, MTA, 615, MUA, 614–615, format, 617–625, MIME, 618–625, RFC 5322, 618, protocols, 615–617, IMAP, 617, POP3, 617, SMTP, 615–617, security, 543, threats, 625–627, 649–650, capabilities, 649–650, characteristics, 649, location, 650, Encapsulating Security Payload (ESP),, 666, 673–680, anti-replay service, 675–676, receiver, 676, replay attack, 675, sender, 676, encryption and authentication, algorithms, 675, 678, format, 674–675, information, 669, padding, 675, protocol operation, 680, transport and tunnel modes, 676–681, Encapsulation, 36, Enciphering, 86, Encipherment, 32, Encoded message (EM) verification,, 436–438, Encrypted messages, types of attacks, on, 90, chosen ciphertext, 90, chosen plaintext, 90, chosen text, 90, ciphertext only, 90, known plaintext, 90, Encrypted payload, 692, Encryption, 86, 292, 543, algorithm, 86, 286, asymmetric, 20, CFB mode, 218, classical, 710–713, conventional, 289, cryptographic suites, 693, 694, and decryption tables for substitution,, 122, DES, 130–131, elliptic curve, 331–333, Feistel cipher, 126, FPE, 233–235, message (See Message encryption), public-key, 288, 289, scheme, computationally secure, 91, unconditionally secure, 91, storage requirements, 226–227, symmetric, 20, wireless security measures, 584, End-to-end encryption, 442, Enhanced nondeterministic random, number generator (ENRNG), 278, Enhanced security services, 637–638, secure mailing lists, 638, security labels, 638, signed receipts, 637, signing certificates, 638
Page 759 :
758, , INDEX, , ENRNG. See Enhanced, nondeterministic random number, generator (ENRNG), Entropy rate, 273, Entropy source, 254, NIST CTR_DRBG, 265, TRNG, 271–272, disk drives, 271–272, sound/video input, 271, Equivalent inverse cipher, 197–199, Error control, external, 386, internal, 386, Error propagation, 215, Error recovery, 215, ESMTP. See Extended SMTP (ESMTP), ESS. See Extended service set (ESS), Euclidean algorithm, 49–52, example, 52, 717–719, extended, 59–61, 719–720, greatest common divisor, 49–50, for polynomials, 156, 163, relatively prime, 49, revisited, 58–59, Euler totient functionality built in, 709–710, Euler’s theorem, 66–67, Euler’s totient function, 65–66, Event detection, 32, Existential forgery, 423, Extended Euclidean algorithm, 719–720, Extended service set (ESS), 590, 593, Extended SMTP (ESMTP), 615, Extensible Authentication Protocol, (EAP), 523–527, authentication methods, EAP-GPSK, 524, EAP-IKEv2, 524, EAP-TLS, 524, EAP-TTLS, 524, exchanges, 524–527, fields, 525–526, -Key packet, 529, layered context, 523, -Logoff packet, 529, messages, code, 525, data, 526, identifier, 525, length, 525, methods, 524, pass-through mode, 525, payload, 692, Extensible Markup Language (XML), 506, External error control, 386, , F, , Factor, 154, Factoring problem, 302–305, Fail-safe defaults, 34–35, Family Educational Rights and Privacy, Act (FERPA), 24, Fast software encryption/decryption, 127, Fault-based attack, 306, FCS. See Frame check sequence (FCS), Federated identity management, 502, identity federation, 504–508, identity management, 503–504, Feedback characteristic of modes of, operation, 225, Feistel cipher, 123–129, confusion, 124–125, decryption, 126, 127–129, design features, 126–127, diffusion, 124–125, encryption, 126, example, 129, parameters, 126–127, structure, 121–123, 125–127, Feistel structure for FPE, 233–238, bit length, 238, , character strings, 235–237, encryption and decryption, 233–235, function FK, 237–238, message length, 238, radix, 238, Fermat’s theorem, 64–65, FERPA. See Family Educational Rights, and Privacy Act (FERPA), Fields, 142, 146–147, 172, multiplicative inverse, 146, types of, 148, Fingerprint templates, 512, Finite fields, 142, 328, 717–723, abelian group, 144–145, arithmetic, 172–174, irreducible, 173, cyclic group, 145, fields, 146–147, of form GF(2n), 157–168, computational considerations, 163–165, generator, 166–168, modular polynomial arithmetic,, 159–161, motivation, 157–159, multiplicative inverse, 161–163, of form GF(p), 147–150, multiplicative inverse, 149–150, order p, 147–149, groups, 143–144, polynomial arithmetic, with coefficients in Zp, 152–155, greatest common divisor, 156–157, ordinary, 151–152, rings, 145–146, Finite group, 144, FIPS PUB 199, 23, Firewall, 523, 589, projects, 701, First assertion, 71–72, Format-preserving encryption (FPE),, 231–245, AES vs., 213, applications, 231–232, difficulties in designing an, 232–233, Feistel structure for, 233–238, bit length, 238, character strings, 235–237, encryption and decryption, 233–235, function FK, 237–238, message length, 238, radix, 238, motivation, 231–232, NIST methods for, 238–245, FF1 algorithm, 239–242, FF2 algorithm, 242–244, FF3 algorithm, 244–245, notation in, 236, parameters in, 236, Forward add round key transformation, (AddRoundKey), 189, Forward mix column transformation, (MixColumns), 186, Forward shift row transformation, (ShiftRows), 185, Forward substitute byte transformation, (SubBytes), 180, Forward unpredictability, 256, 4-way handshake, 606, FPE. See Format-preserving encryption, (FPE), Frame check sequence (FCS), 386, 592, Frequency test, 256, , G, , Galois/counter mode (GCM), 405–408, authentication and encryption, functions, 406, message authentication code, 407, Generalized number field sieve (GNFS),, 303, , Generate function, 266, Generator, 145, 166–168, Generic chosen message attack, 422, GMK. See Group master key (GMK), GNFS. See Generalized number field, sieve (GNFS), Greatest common divisor, 49–50, finding, 50–52, 156–157, Group master key (GMK), 605, Group temporal key (GTK), 605, Groups, 143–144, associative, 143, closure, 143, commutative, 144, cyclic, 145, distribution, 607, finite, 144, generate, 145, generator, 145, identity element, 144, infinite, 144, inverse element, 144, keys, 605–607, order of, 144, permutation, 144, , H, , Hacking project, 698–699, Handshake protocol, action, 557, CipherSpec, Cipher algorithm, 558, Cipher type, 558, hash size, 558, is exportable, 558, IV size, 558, key material, 558, MAC algorithm, 558, CipherSuite parameter, anonymous Diffie-Hellman, 558, ephemeral Diffie-Hellman, 558, fixed Diffie-Hellman, 558, Fortezza, 558, RSA, 558, client authentication and key, exchange, 559–560, certificate message, 560, ephemeral or anonymous DiffieHellman, 559, fixed Diffie-Hellman, 560, Fortezza, 560, RSA, 560, finished message, 561, security capabilities, 556–558, cipher suite, 557, compression method, 557, random, 556, session ID, 556, version, 556, server authentication and key, exchange, 559–560, anonymous Diffie-Hellman, 559, ephemeral Diffie-Hellman, 559, Fortezza, 559, RSA key exchange, 559, Hardware fault-based attack, 302, Hash code, 353, digital signature, 345, message authentication, 343–344, secure, general structure of, 353, Hash functions, 340, 384, attack against, 342, based on cipher block chaining,, 354–355, birthday attack, 355, meet-in-the-middle-attack, 355, cryptographic, 340–376, 739–741, applications of, 341–346, brute-force attacks, 350–353, collision, 348
Page 760 :
INDEX, collision resistant, 349, cryptanalysis, 353–354, digital signatures, 344–345, intrusion detection, 345, message authentication, 341–344, one-way password file, 345, preimage, 348, preimage resistant, 349, PRF, 346, PRNG, 346, properties, relationship, 350, pseudorandomness, 350, requirements and security, 348–354, resistance properties, 350, second preimage resistant, 349, virus detection, 345, keyed, 344, and message authentication codes,, 258, 394–398, PRNG on, 413–414, resistance properties, 350, strong, 349, TRNG, 273–274, two simple, 346–348, Hash value, 349, 351, 356, Header fields, 619–620, Content-Description, 620, Content-ID, 620, Content-Transfer-Encoding, 620, Content-Type, 619, MIME-Version, 619, Health testing, 274–276, on conditioning function, 276, on noise source, 274–276, Hill cipher, 99–102, algorithm, 100–102, concepts from linear algebra, 99–100, determinant, 99, HMAC, 394–398, algorithm, 395–398, design objectives, 395, efficient implementation of, 397, security of, 398, structure, 396, HTTPS (HTTP over SSL), 566–567, connection closure, 567, connection initiation, 566–567, Human attack surface, 38, Hybrid cloud, 532, , I, , IaaS. See Infrastructure as a service, (IaaS), Ideal block cipher, 121–123, Identification payload, 691, Identification string exchange, 570, Identities, 56, Identity and access management (IAM),, 542, Identity element, 56, 144, 322, Identity federation, 504–508, examples, 507–508, scenarios, 507, standards, 506–507, SAML, 506, SOAP, 506, WS-Security, 506, XML, 506, Identity management system, administrators, 504, attribute service, 503, authorization, 503, data consumers, 504, identity provider, 503, identity services, 503, key services, 503, management, 503, point of contact, 503, principal, 503, provisioning, 503, , SSO protocol services, 503, trust services, 503, Identity provider, 503, Identity theft (MAC spoofing), 583, IEEE 802.11 wireless LAN, 589–595, association-related services, 594–595, association, 595, BSS transition, 595, disassociation, 595, ESS transition, 595, no transition, 595, reassociation, 595, MPDU format, 592, network components and architectural, model, 592–593, ESS, 593, protocol architecture, 590–592, logical link control, 592, media access control, 591–592, physical layer, 590, protocol stack, 591, services, 593–595, association-related services, 594–595, distribution of messages within a, DS, 594, terminology, 590, Wi-Fi alliance, 590, IEEE 802.11i wireless LAN security,, 595–609, authentication phase, 601–603, access control approach, 601, EAP exchange, 602–603, MPDU exchange, 602, discovery phase, 599–601, MPDU exchange, 600–601, security capabilities, 600, elements of, 597, key management phase, 603–607, group key distribution, 607, group keys, 605–606, pairwise key distribution, 606–607, pairwise keys, 605, phases of operation, 596–599, authentication, 598, connection termination, 599, discovery, 598, key generation and distribution, 598, protected data transfer, 598, protected data transfer phase,, 607–608, CCMP, 608, TKIP, 607–608, pseudorandom function, 608–609, services, 596, access control, 596, authentication, 596, privacy with message integrity, 596, IEEE 802.1X Port-Based NAC, 527–529, access control, 528, EAPOL, 528, terminology, 527, IKE. See Internet Key Exchange (IKE), IKEv2 Exchanges, 687–688, IMAP. See Internet Mail Access Protocol, (IMAP), Independent BSS (IBSS), 592, Indeterminate, 151, Index, 76, Infinite field, 147, Infinite group, 144, Information access threats, 42, Informational exchange, 688, Infrastructure as a service (IaaS), 532, Initialization value (IV), 675, Initialization vectors, 551, Injection of commands, 40, Inputs, ANSI X9.17 PRNG, 263, for single AES round, 190, sound/video, 271, , 759, , Instructor’s Resource Center (IRC), 697, Integral domain, 146, Integration, 594, Integrity, 22, 24, data, 22, system, 22, Integrity-related threats, 625, Intel digital random number generator,, 276–279, hardware architecture, 277–278, logical structure, 278–279, Internal error control, 386, International Organization for, Standardization (ISO), 44, Internet Architecture Board (IAB),, 662, Internet banking server (IBS), 40, Internet Key Exchange (IKE), 666, header and payload formats, 688–692, key determination, authentication, 687, cookie exchange, 686, features, 686–687, IKEv2 Exchanges, 687–688, nonces, 687, protocol, 684–688, payload types, 689–692, requirements, 686, Internet Mail Access Protocol (IMAP),, 617, Internet mail architecture, 613–617, email components, 614–615, ADMD, 615, DNS, 615, MDA, 615, MHS, 614, MS, 615, MSA, 615, MTA, 615, MUA, 614–615, email protocols, 615–617, IMAP, 617, POP3, 617, SMTP, 615–617, Internet security, 20, Internet Security Association and, Key Management Protocol, (ISAKMP), 684, Internet Service Provider (ISP), 663, Internet Society (ISOC), 43, Intruder, 42–43, Intrusion detection, 345, Intrusion management, 543, Inverse add round key transformation,, 189, Inverse element, 55, 144, 322, Inverse mix column transformation, (InvMixColumns), 187, Inverse shift row transformation, (InvShiftRows), 185, Inverse substitute byte transformation, (InvSubBytes), 184, Invisible ink, 110, InvMixColumns, 198–199, InvShiftRows, 198, InvSubByte, 198, Iota step function, 376, IP security (IPsec), 662–694, applications, 663–664, architecture, 669, authentication plus confidentiality,, 681–682, benefits of, 664–665, destination address, 668, documents, 665–666, AH, 666, architecture, 665, cryptographic algorithms, 666, ESP, 666, IKE, 666
Page 761 :
760, , INDEX, , IP security (IPsec) (Continued), ESP, 673–680, anti-replay service, 675–676, encryption and authentication, algorithms, 675, 678, format, 674–675, information, 669, padding, 675, protocol operation, 680, transport and tunnel modes,, 676–680, IKE, 666, header and payload formats,, 688–692, key determination protocol,, 684–688, routing applications, 665, SA, 668, combinations of, 682–684, IP destination address, 668, Security Protocol Identifier, 668, SPI, 668, SAD, 668, 669–670, AH information, 669, Anti-Replay Window, 669, ESP information, 669, IPsec Protocol Mode, 670, Lifetime of this Security, Association, 669, Path MTU, 670, Sequence Counter Overflow, 669, Sequence Number Counter, 669, SPI, 669, services, 666, SPD, 668, 670–671, local and remote ports, 671, local IP address, 670, name, 671, next layer protocol, 670, remote IP address, 670, traffic processing, 671–673, inbound packets, 672–673, outbound packets, 671–672, transport and tunnel modes, 666–668, VPN scenario, 664, IPv4, 663, IPv6, 663, 667, Iris images, 512, Irreducible polynomial, 154, 173, Irreversible mapping, 121, ISAKMP. See Internet Security, Association and Key, Management Protocol, (ISAKMP), IS-Box, 181, 182, Isolation, 36, ISP. See Internet Service Provider (ISP), Iteration function, 365, ITU Telecommunication Standardization, Sector (ITU-T), 43, , K, , Keccak, 365, 367, 371, 373, KEK. See Key encryption key (KEK), Kerberos, 482–500, environmental shortcomings, authentication forwarding, 495, encryption system dependence, 495, internet protocol dependence, 495, interrealm authentication, 495, message byte ordering, 495, ticket lifetime, 495, exchanges, 491, motivation, 483–484, reliable, 484, scalable, 484, secure, 484, transparent, 484, overview of, 489, principal, 493, , technical deficiencies, double encryption, 496, password attacks, 496, PCBC encryption, 496, session keys, 496, Version 4, 484–494, authentication dialogue, 488–490, authentication service exchange, 491, client/server authentication, exchange, 492, message exchanges, 488, protocol, 491, secure authentication dialogue,, 486–488, simple authentication dialogue,, 484–485, ticket-granting service exchange,, 492, Version 5, 495–500, authentication dialogue, 496–498, authentication service exchange, 496, message exchanges, 497, nonce, 497, options, 497, realm, 497, ticket flags, 498–500, ticket-granting service exchange,, 497, times, 497, Kerberos realm, 490, 493–494, Key, ANSI X9.17 PRNG, 263, asymmetric encryption, 288, determination protocol, 684–688, expansion algorithm, 190–192, generation, 301–302, length, 265, schedule algorithm, 137, size, 127, 3DES, 210–213, unwrapping, 410–413, Key distribution center (KDC), 444–446,, 478–481, Key distribution, symmetric, using asymmetric encryption, 451–454, hybrid scheme, 454, secret key distribution, 453, simple secret key distribution,, 451–453, using symmetric encryption, 442–451, controlling key usage, 449–451, decentralized key control, 448–449, hierarchical key control, 446, key distribution scenario, 444–446, session key lifetime, 446–447, transparent key control scheme,, 447–448, Key distribution technique, 442, Key encryption key (KEK), 408, Key exchange, 292, 571, Diffie-Hellman, 314–315, algorithm, 315–316, 685–686, analog, 331, discrete logarithm, 315, example, 734, 738–739, key exchange protocols, 317, man-in-the-middle attack, 317–318, payload, 691, Key management and distribution, hierarchy, 444, public keys distribution, 454–459, public-key infrastructure, 467–469, symmetric key distribution, using asymmetric encryption,, 451–454, using symmetric encryption, 442–451, X.509 certificates, 459–467, Key management key, 512, Key usage, 466, Key Wrap (KW) mode, 408–409, , Key wrapping, algorithm, 409–410, KEK, 408, operation for 256-bit key, 411, and unwrapping, 410–413, Keyed hash function, 344, Key-only attack, 422, Keystream, 267, 268, Known message attack, 422, Known-plaintext, 90, attack on triple Data Encryption, Standard, 211, 212, Koblitz curve, 736, KW mode. See Key Wrap (KW) mode, , L, , Lanes, 369, 370, Layering, 37, Least astonishment, 37, Least common mechanism, 36, Least privilege, 35–36, Linear algebra and matrix functionality,, 704–705, Linear congruential generators, 258–259,, 730–731, Local forwarding, 578, Lucifer cipher, 233, , M, , MAC protocol data unit (MPDU), 590, 591, CRC, 592, destination MAC address, 591, exchange, 600–601, AS, 602, association, 600–601, EAP exchange, 602, network and security capability, discovery, 600, open system authentication, 600, secure key delivery, 602, format, 592, MAC Control, 591, MAC header, 591, MAC trailer, 592, MSDU, 591, source MAC address, 591, MAC service data unit (MSDU), 590,, 591, 594, Mail Delivery Agent (MDA), 615, Mail Submission Agent (MSA), 615, Malicious association, 583, Management information base (MIB), content, 666, Man-in-the-middle attacks, 317–318, 451,, 452, 583, Manual key management, 684, Mapping, definition, 123, irreversible, 121, nonsingular, 121, policy, 466, reversible, 121, Mask generation function (MGF), 307,, 433–434, Masquerade, 28, 383, Master key, 444, 448, Master secret, 551, 560, Diffie-Hellman, 560, RSA, 560, Master session key (MSK), 605, Matching Type field, 644, Mathematical attacks, 302, Maurer’s universal statistical test, 256, MD4, 356, MD5, 353, 365, MDA. See Mail Delivery Agent (MDA), Measured service, 531, Media access control (MAC), 591, Media gateway, 521, Meet-in-the-middle attack, 210, 355
Page 762 :
INDEX, Message authentication, 341–344, attack against hash function, 342, cryptographic suites, 693, 694, functions, 383–390, hash function, 384, MAC, 388–390, message encryption, 384–388, hash code, 343–344, keyed hash function, 344, message digest, 341, requirements, 382–383, content modification, 383, destination repudiation, 383, disclosure, 382, masquerade, 383, sequence modification, 383, source repudiation, 383, timing modification, 383, traffic analysis, 383, simplified examples, 343, Message authentication code (MAC),, 344, 382, 552, authenticated encryption, 402–408, CMAC, 402–405, GCM, 405–408, basic uses of, 389, on block ciphers, 399–401, CMAC, 400–401, DAA, 399–400, HMAC, 394–398, algorithm, 395–398, design objectives, 395, efficient implementation of, 397, security of, 398, structure, 396, key wrapping, 408–413, algorithm, 409–410, KEK, 408, operation for 256-bit key, 411, and unwrapping, 410–413, PRNG using, 415, requirements for, 391–393, security of, 393–394, brute-force attacks, 393–394, computation resistance, 393, cryptanalysis, 394, Message digest, 341, generation using SHA-512, 357, Message encryption, 384–388, basic uses of, 384, public-key encryption, 387–388, symmetric encryption, 384–387, external error control, 386, internal error control, 386, TCP segment, 387, Message Handling Service (MHS), 614, Message integrity, 551, CCMP, 608, TKIP, 607, Message integrity code (MIC), 607, Message length, 238, Message Store (MS), 615, Message Transfer Agent (MTA), 615, Message type, 622, Message User Agents (MUA), 614–615, Message/external-body subtype, 622, Message/partial subtype, 622, Message/rfc822 subtype, 622, MIC. See Message integrity code (MIC), Micali-Schnorr PRNG, 334, Michael, 607, 608, Miller-Rabin algorithm, 68–70, details of, 69, properties of prime numbers, 68–69, first property, 68, second property, 68, repeated use of, 70, Miller–Rabin primality test, 706–707, MIME. See Multipurpose Internet Mail, Extension (MIME), , MIME-Version header fields, 619, MixColumns, 174, 177, 200, transformation, 186–189, 205–206, Mobile device security, 585–589, cloud-based applications, 585, de-perimeterization, 586, external business requirements, 586, growing use of new devices, 585, strategy, 587–589, barrier security, 589, device security, 587–589, elements, 586, traffic security, 589, threats, 586–587, interaction with other systems, 587, lack of physical security controls,, 586, location services, 587, by unknown parties, 587, untrusted content, 587, untrusted mobile devices, 586, untrusted networks, 587, Modification of messages, 28, Modular arithmetic, 53–61, 149, 157, 161, congruences, 53, congruent modulo n, 35, Euclidean algorithm, extended, 59–61, revisited, 58–59, exponentiation in, 298–299, modulus, 53, operations, 54–55, properties of, 55–58, 298, reducing k modulo n, 56, set of residues/residue classes, 56, Modular exponentiation, 707–708, built-in Sage functionality for, 709, Modular polynomial arithmetic, 159–161, Modularity, 36–37, Modulus, 53, 83, Monic polynomial, 151, Monoalphabetic ciphers, 94–97, digrams, 96, permutation, 94, relative frequency, 95, 96, substitution cipher, 94, Multi-instance model, 539, Multipart type, 621, Multipart/alternative subtype, 621–622, Multipart/digest subtype, 622, Multipart/mixed subtype, 621, Multipart/parallel subtype, 621, Multiple encryption, 208–213, double DES, 208–210, meet-in-the-middle attack, 210, reduction to single stage, 209–210, triple DES, known-plaintext attack on, 212, with three keys, 213, with two keys, 210–213, Multiplication, 145–146, 164–165, 206, Multiplicative identity, 146, Multiplicative inverse, 146, 149–150,, 161–163, Multipurpose Internet Mail Extension, (MIME), 618–625, canonical form, 625, content types, 620–622, application type, 622, message type, 622, message/external-body subtype, 622, message/partial subtype, 622, message/rfc822 subtype, 622, multipart type, 621, multipart/alternative subtype,, 621–622, multipart/digest subtype, 622, multipart/mixed subtype, 621, multipart/parallel subtype, 621, text type, 621, , 761, , header fields, 619–620, Content-Description, 620, Content-ID, 620, Content-Transfer-Encoding, 620, Content-Type, 619, MIME-Version, 619, message structure, 624, multipart example, 623, native form, 623–625, specification, 619, transfer encodings, 622–623, base64 transfer encoding, 623, quoted-printable, 623, use of, 619, Multirate padding, 366, Multi-tenant model, 539, Mutual authentication, asymmetric encryption, 500–501, remote user-authentication principles,, 477–478, symmetric encryption, 478–481, , N, , NAC. See Network access control (NAC), NAS. See Network access server (NAS), National Institute of Standards and, Technology (NIST), 43, 129, 172, digital signature algorithm, 426–430, for electronic user authentication,, 475–476, FPE, 238–245, FF1 algorithm, 239–242, FF2 algorithm, 242–244, FF3 algorithm, 244–245, Native form, 623–625, Network access control (NAC), 520–523, context, 521, elements of, AR, 520, NAS, 521, policy server, 520, enforcement methods, 522–523, DHCP management, 523, firewall, 523, IEEE 802.1X, 522, VLANs, 522, Network access server (NAS), 521, Network attack surface, 37, Network injection attack, 584, Network security, 20, 543–544. See also, Cryptography, access model, 42, basic tasks, 42, cryptography and, block cipher projects, 699, case studies, 701, firewall projects, 701, hacking project, 698–699, laboratory exercises, 699, practical security assessments,, 700–701, programming projects, 700, reading/report assignments, 702, research projects, 699–700, sage computer algebra projects,, 697–698, writing assignments, 701–702, model for, 41–43, secret information, 41, security-related transformation, 41, threats, information access, 42, service, 42, Next-bit test, 260, NIST. See National Institute of Standards, and Technology (NIST), NIST CTR_DRBG, 264–267, entropy source, 265, functions, 266, generate, 266
Page 763 :
762, , INDEX, , NIST CTR_DRBG (Continued), initialize, 265, key length, 265, output block length, 265, parameters, 265, reseed interval, 265, seed length, 265, update, 266–267, No zero divisors, 146, Nonce, 217, 445, 478, 687, payload, 691, Non-deterministic random bit, generators (NRBGs) model, 275, Nonrepudiation, 30, 31, Nonsingular mapping, 121, Nontraditional networks, 583, Notarization, 33, Notify payload, 691, NRBGs model. See Non-deterministic, random bit generators (NRBGs), model, Number of rounds, 127, 136, Number theory, 705–710, Chinese remainder theorem, 71–73,, 705–706, discrete logarithms, 73–78, calculation of, 77–78, for modular arithmetic, 75–77, powers of integer, 73–75, divisibility, 47–48, division algorithm, 48–49, Euclidean algorithm, 49–52, Euler totient functionality built in,, 709–710, Euler’s theorem, 66–67, Euler’s totient function, 65–66, Fermat’s theorem, 64–65, and finite fields, 717–723, Miller–Rabin primality test, 706–707, modular arithmetic, 53–61, Euclidean algorithm revisited, 58–59, extended Euclidean algorithm,, 59–61, modular arithmetic operations,, 54–55, modulus, 53, properties of, 55–58, properties of congruences, 53, modular exponentiation, 707–709, primality, testing for, 68–70, algorithm, 70, distribution of primes, 70, Miller-Rabin algorithm, 68–70, prime numbers, 61–64, , O, , OAEP. See Optimal asymmetric, encryption padding (OAEP), Oakley Key Determination Protocol,, 684, OFB mode. See Output feedback (OFB), mode, On-demand self-service, 531, One-time pad, 105–106, One-way authentication, asymmetric encryption, 501–502, remote user-authentication principles,, 478, symmetric encryption, 482, One-way function, 293, One-way password file, 345, Open design, 35, Open Shortest Path First (OSPF), 665, Optimal asymmetric encryption padding, (OAEP), 307–308, Order, 70, 74, Order of group, 144, Ordinary polynomial arithmetic, 151–152, OSI security architecture, ITU-T3 Recommendation X.800, 26, , security attack, 26, security mechanism, 26, security service, 26, threats and attacks, 27, OSPF. See Open Shortest Path First (OSPF), Output, 264, Output block length, 265, Output feedback (OFB) mode, 218,, 220–222, , P, , PaaS. See Platform as a service (PaaS), Pairwise master key (PMK), 605, Pairwise transient key (PTK), 605, Parameters, SHA, 356, SHA-3, 369, Passive attack, 27, release of message contents, 27, traffic analysis, 27, Password attacks, 496, Path MTU, 670, Peer certificate, 550, Peer entity authentication, 29, 30, Perfect secrecy, 106, Permutation, 94, 125, 131, 144, Permuted input, 130, Personal identification number (PIN),, 476, 511, Personal identity verification (PIV), authentication, 512–514, authentication key, 512, card application administration key,, 512, card issuance and management, subsystem, 509, credentials and keys, 511–512, documentation, 510–511, FIPS 201 PIV system model, 510, front-end subsystem, 509, system model, 509–510, PGP. See Pretty Good Privacy (PGP), Pi step function, 374–375, PIN. See Personal identification number, (PIN), Pin punctures, 110, PIV. See Personal identity verification, (PIV), PKI. See Public key infrastructure (PKI), Plaintext, 86, 286, transforming to ciphertext, 89, Plaintext–ciphertext pair, 210, Platform as a service (PaaS), 532, Playfair cipher, 97–99, monarchy, 97, plaintext, 98, relative frequency of letters, 98, PMK. See Pairwise master key (PMK), Point at infinity, 323, Policy mappings, 466, Policy server, 520, 521, Pollard rho method, 333, Polyalphabetic ciphers, 102–105, autokey system, 104, one-time pad, 105–106, polyalphabetic substitution cipher, 102, substitution cipher, 102, Vernam cipher, 104–105, Vigenère cipher, 102–104, Polynomial, arithmetic, coefficient set, 151, with coefficients in Zp, 152–155, constant polynomial, 151, Euclidean algorithm for, 156, 163, examples of, 153, 155, greatest common divisor, 156–157, indeterminate, 151, modular, 159–161, monic polynomial, 151, , ordinary, 151–152, treatment of, 151, with coefficients in GF(28), 203–206, ring, 152, root of, 166, Port, 576–578, Post Office Protocol (POP3), 617, Practical security assessments, 700–701, Preimage, 348, attacks, 351, brute-force attacks, 351, Preimage resistant, 349, Preoutput, 131, Pre-shared key (PSK), 605, Pretty Good Privacy (PGP), 638–639, PRF. See Pseudorandom function (PRF), Primality, testing for, 68–70, algorithm, 70, distribution of primes, 70, Miller–Rabin algorithm, 68–70, 706–707, details of, 69, repeated use of, 70, two properties of prime numbers,, 68–69, Prime curve, 325, Prime number, 61–64, 149, 158, Prime polynomial, 154, Primitive root, 74, 314, Privacy, 21, Private cloud, 532, Private keys, 287, 288, certificate, 285, RSA algorithm, 300–301, Private-key usage period, 466, PRNG. See Pseudorandom number, generator (PRNG), Product cipher, 123, 124, Product systems, 89, Programming projects, 700, Propagating cipher block chaining, (PCBC) encryption, 496, Pseudorandom function (PRF), 253–255,, 334, 346, 413, cryptographic suites, 693, 694, Pseudorandom number generator, (PRNG), 253–255, 346, 729–731, Blum Blum Shub generator, 260–261,, 729–730, on elliptic curve cryptography, 336, on hash function, 413–414, linear congruential generators,, 258–259, 730–731, MAC function, 415, next-bit test, 260, principles of, 252–258, algorithm design, 257–258, requirements, 255–257, TRNGs, PRNGs, and PRFs, 253–255, use of random numbers, 252–253, randomness, 255–256, consistency, 255, frequency test, 256, Maurer’s universal statistical test, 256, runs test, 256, scalability, 255, uniformity, 255, requirements, 255–257, on RSA, 334–335, seed requirements, 256–257, unpredictability, backward, 256, forward, 256, using block cipher, 261–267, ANSI X9.17 PRNG, 263–264, mechanisms, 262, NIST CTR_DRBG, 264–267, Pseudorandom numbers, 253, Pseudorandomness, 350, PSK. See Pre-shared key (PSK), Psychological acceptability, 36
Page 764 :
INDEX, PTK. See Pairwise transient key (PTK), Public cloud, 532, Public key infrastructure (PKI), 285, 513, Public keys, 287, 288, 454–459, (asymmetric) cryptographic algorithm,, 285, authority, 456–457, certificates, 457–459, cryptanalysis, 294, public announcement of, 454–455, publicly available directory, 455–456, RSA algorithm, 299–300, uncontrolled distribution, 455, Public-key cryptography, 284, 731–739, applications for, 291–292, decryption, 292, digital signature, 292, encryption, 292, key exchange, 292, authentication, 290, 291, characteristics, 286, ciphertext, 287, confidentiality, 289, conventional encryption, 289, decryption algorithm, 288, digital signature, 290, encryption algorithm, 286, misconception, 284, plaintext, 286, principles of, 285–294, public and private keys, 287, 288, public-key cryptanalysis, 294, public-key encryption, 286–288, requirements for, 292–294, one-way function, 293, trap-door one-way function, 293, secrecy, 291, secret key, 288, Public-key encryption, 286–289, 387–388,, 687, Public-key infrastructure X.509 (PKIX), elements, certification authority, 467, CRL issuer, 467, end entity, 467, registration authority, 467, repository, 467, management functions, certification, 468, cross certification, 469, initialization, 468, key pair recovery, 468–469, key pair update, 469, registration, 468, revocation request, 469, management protocols, 469, Publicly available directory, 455–456, Purpose-built algorithms, 257, Puzzle for Inspector Morse, 111, , Q, , Quoted-printable transfer encodings, 623, , R, , Radix, 236, 238, Rail fence cipher, 107, Random delay, 306, Random numbers, generator, 218, 254, randomness, 252–253, independence, 252, uniform distribution, 252, unpredictability, 253, use of, 252–253, Randomization approach, 253, Randomness, 252–253, characteristics, 255, consistency, 255, frequency test, 256, independence, 252, , Maurer’s universal statistical test, 256, runs test, 256, scalability, 255, tests, 256, uniform distribution, 252, uniformity, 255, Rapid elasticity, 531, RAS. See Remote access server (RAS), RC4, 268–271, initialization of S, 269, stream generation, 270, strength of, 271, Read-only memory (ROM), 509, Realm, 493, Registration authority (RA), 475, Relatively prime, 49, 57, 148, Release of message contents, 27, Relying party (RP), 476, Relying subsystem, 510, Remote access server (RAS), 521, Remote forwarding, 578, Remote user-authentication, principles, challenge/response, 478, identification step, 474, mutual authentication, 477–478, NIST model, 475–476, one-way authentication, 478, something the individual does, (dynamic biometrics), 476, something the individual is (static, biometrics), 476, something the individual knows, 476, something the individual possesses,, 476, verification step, 474, using asymmetric encryption, mutual authentication, 500–501, one-way authentication, 501–502, using symmetric encryption, mutual authentication, 478–481, one-way authentication, 482, Repetition Count Test, 275–276, Replay, 28, Replay attack, 477, 675, Research projects, 699–700, Reseed interval, 265–267, Residue, 49, 83, 148, 161, Residue classes, 56, 84, Resource pooling, 531–532, Resource records (RRs), 639, 640, Reversible mapping, 121, RFC 4686, 649–650, capabilities, 649–650, characteristics, 649, location, 650, RFC 5322, 618, Rho step function, 373–374, Rijndael, 172, 174, 185, 192, 199, Rings, 145–146, associativity of multiplication, 145, closure under multiplication, 145, commutativity of multiplication, 145, distributive laws, 145, integral domain, 146, multiplicative identity, 146, no zero divisors, 146, Rivest-Shamir-Adleman (RSA), algorithm, 286, 294–308, 731–734, computational aspects, 297–302, exponentiation in modular, arithmetic, 298–299, key generation, 301–302, private key, 300–301, public key, 299–300, description of, 295–297, example of, 297, PRNG on, 334–335, processing of multiple blocks, 298, security of, 302–308, , 763, , brute force attacks, 302, CCA, 302, 307–308, factoring problem, 302–305, fault-based attack, 306, hardware fault-based attack, 302, mathematical attacks, 302, MIPS-years needed to factor, 304, OAEP, 307–308, timing attacks, 302, 305–306, Robust Security Network (RSN), 596, Rotor machines, 108–110, DES, 110, multiple cylinders, 109, single-cylinder system, 109, with wiring represented by numbered, contacts, 109, Round, 131, 132, constants in SHA-3, 376, function, 125, 127, 360–364, Routing control, 33, RRs. See Resource records (RRs), RSA algorithm. See Rivest-ShamirAdleman (RSA) algorithm, RSA-PSS digital signature algorithm, mask generation function, 433–434, signature verification, 436–438, signing operation, 434–436, RSN. See Robust Security Network, (RSN), Runs test, 256, , S, , SaaS. See Software as a service (SaaS), Sage computer algebra projects, 697–698, SAML. See Security Assertion Markup, Language (SAML), S-Box, 180, 181, 185, Scalability, 255, Schnorr digital signature scheme, 425–426, SecaaS. See Security as a service (SecaaS), Second assertion, 72, Second preimage, attacks, 351, brute-force attacks, 351, Second preimage resistant, 349, Secret information, 41, Secret key, 86, 288, Secret-key encryption, 89, Secure Hash Algorithm (SHA), 355–364, Secure shell (SSH), connection protocol, 574–578, transport layer security, 567–578, User Authentication Protocol, 573–574, Secure/Multipurpose Internet Mail, Extension (S/MIME), 625,, 627–638, certificate processing, 637, cryptographic algorithms, 632–633, MUST, 632, SHOULD, 632–633, DANE, 645, enhanced security services, 637–638, secure mailing lists, 638, security labels, 638, signed receipts, 637, signing certificates, 638, messages, 633–637, certificates-only message, 637, clear signing, 636, compressedData, 632, envelopedData, 632, 634–635, registration request, 636–637, signedData, 632, 635–636, operational description, 628–632, authentication, 628–630, compression, 631–632, confidentiality, 629–630, email compatibility, 630–631, simplified functional flow, 631, user agent role, 637
Page 765 :
764, , INDEX, , Security as a service (SecaaS), 541, Security Assertion Markup Language, (SAML), 506, Security assessments, 543, Security association database (SAD),, 668, 669–670, AH information, 669, Anti-Replay Window, 669, ESP information, 669, IPsec Protocol Mode, 670, Lifetime of this Security Association,, 669, Path MTU, 670, Sequence Counter Overflow, 669, Sequence Number Counter, 669, SPI, 669, Security associations (SA), 668, authentication plus confidentiality,, 681–682, ESP with authentication option, 681, transport adjacency, 682, transport-tunnel bundle, 682, combinations of, 682–684, IP destination address, 668, lifetime of, 669, payload, attribute, 690, proposal, 690, transform, 690, Security Protocol Identifier, 668, SPI, 668, Security attacks, 26–29, active attacks, 27–29, denial of service, 29, masquerade, 28, modification of messages, 28, replay, 28, passive attack, 27, release of message contents, 27, traffic analysis, 27, Security audit trail, 32, Security design principles, complete mediation, 35, economy of mechanism, 34, encapsulation, 36, fail-safe defaults, 34–35, isolation, 36, layering, 37, least astonishment, 37, least common mechanism, 36, least privilege, 35–36, modularity, 36–37, open design, 35, psychological acceptability, 36, separation of privilege, 35, “Security in the Internet Architecture”, (RFC 1636), 662, Security information and event, management (SIEM), 543, Security label, 32, Security mechanisms, cryptographic hash functions, 348–350, collision resistant, 349, preimage resistant, 349, pseudorandomness, 350, second preimage resistant, 349, ECB, 216, MAC, 393–394, based on hash functions, 398, brute-force attacks, 393–394, computation resistance, 393, cryptanalysis, 394, pervasive, event detection, 32, security audit trail, 32, security label, 32, security recovery, 32, trusted functionality, 32, RSA algorithm, 302–308, brute force attacks, 302, , CCA, 302, 307–308, factoring problem, 302–305, fault-based attack, 306, hardware fault-based attack, 302, mathematical attacks, 302, MIPS-years needed to factor, 304, OAEP, 307–308, timing attacks, 302, 305–306, services, 29–33, access control, 31, availability service, 32–33, data confidentiality, 30, 31, data integrity, 30, 31, nonrepudiation, 30, 31, specific, access control, 32, authentication exchange, 33, data integrity, 32, digital signature, 32, encipherment, 32, notarization, 33, routing control, 33, traffic padding, 33, Security Parameter Index (SPI),, 668, 669, Security policy database (SPD),, 668, 670–671, local and remote ports, 671, local IP address, 670, name, 671, next layer protocol, 670, remote IP address, 670, Security policy violation, 40, Security Protocol Identifier, 668, Security recovery, 32, Security services (X.800), 29–30, Security-related transformation, 41, Seed, 254, 265, input to PRNG, 257, requirements, 256–257, Seed length, 265, Selective forgery, 423, Selective-field confidentiality, 30, Selector field, 644, Selectors, 670, Sender Policy Framework (SPF), 626,, 645–648, mechanisms, 647, modifiers, 647, operation, 648, on receiver side, 647–648, on sender side, 647, Separation of privilege, 35, Sequence Counter Overflow, 669, Sequence Number Counter, 669, Sequence numbers, 498, 551, Server and client random, 551, Server write key, 551, Server write MAC secret, 551, Service aggregation, 535, Service arbitrage, 535, Service intermediation, 535, Service threats, 42, Session identifier, 550, Session key, 444, 496, Session security module (SSM),, 447–448, Set of residues, 56, SHA. See Secure Hash Algorithm, (SHA), SHA-0, 356, SHA-1, 356, SHA-2, 356, SHA-3, 365–376, iteration function f, 369–376, Chi step function, 375–376, composition, 370, constants in SHA-3, 376, Iota step function, 376, Pi step function, 374–375, , Rho step function, 373–374, structure of, 370–371, theta step function, 371–373, parameters, 369, sponge construction, 365–369, absorbing phase, 367, 368, bitrate, 365, capacity, 367, iteration function, 365, multirate padding, 366, simple padding, 366, sponge function input and output,, 366, squeezing phase, 368, state matrix, 370, step functions in, 371, SHA-224, 356, SHA-256, 356, SHA-384, 356, SHA-512, 356, constants, 359, logic, 356–359, big-endian format, 358, step 1 append padding bits, 357, step 2 append length, 357, step 3 initialize hash buffer, 357–358, step 4 process message in 1024-bit, (128-byte) blocks, 358–359, step 5 output, 359, message digest generation using, 357, round function, 360–364, ShiftRows, 174, 177, 200, AES row and column operations, 186, forward shift row transformation, 185, inverse shift row transformation, 185, SIEM. See Security information and, event management (SIEM), Signal-hiding techniques, 584, Signature verification, decryption, 436, EM verification, 436–438, Signing operation, forming the signature, 436, message encoding, 434–436, Simple Mail Transfer Protocol (SMTP),, 615–617, 645, Simple Network Management Protocol, Version 3 (SNMPv3), 390, Simple Object Access Protocol (SOAP),, 506, Simple padding, 366, Simplified AES (S-AES), 724–729, Single sign-on (SSO), 503, Single-cylinder system, 109, Single-key encryption, 86, 89, Skew, 273, S/MIME. See Secure/Multipurpose, Internet Mail Extension (S/, MIME), SMTP. See Simple Mail Transfer, Protocol (SMTP), Software as a service (SaaS), 532, Software attack surface, 38, Sound/video input, 271, SPD. See Security policy database (SPD), Special number field sieve (SNFS), 303,, 304, Sponge construction, 365–369, absorbing phase, 367, 368, bitrate, 365, capacity, 367, iteration function, 365, multirate padding, 366, simple padding, 366, sponge function input and output, 366, squeezing phase, 368, Sponge function input and output, 366, Squeezing phase, 368, Standards, 43–44, STARTTLS, 617, 625
Page 766 :
INDEX, State, 174, State array, 174, State matrix, 370, Static biometrics, 476, Steganography, 110–111, advantage, 111, character marking, 110, drawbacks, 111, invisible ink, 110, pin punctures, 110, typewriter correction ribbon, 110, Stream ciphers, 120–121, 267–268,, 729–731, advantage of, 268, design considerations for, 268, processes, 89, RC4, 268–271, initialization of S, 269, stream generation, 270, strength of, 271, Stream generation, 270, Strict avalanche criterion (SAC), 136, SubBytes, 174, 180, 200, Subject key identifier, 466, Subkey, 127, 131, 498, Subscriber, 475–476, Substitute bytes, 177, 180–185, AES byte-level operations, 180, constuction of S-Box and IS-Box, 182, forward substitute byte, transformation, 180, inverse substitute byte transformation,, 184, Substitution techniques, 92–106, 122,, 123, 125, Caesar cipher, 92–94, Hill cipher, 99–102, monoalphabetic ciphers, 94–97, one-time pad, 105–106, playfair cipher, 97–99, polyalphabetic ciphers, 102–105, Substitution-permutation network, (SPN), 125, Supplicants, 520, 525, Suppress-replay attacks, 480, Symmetric block ciphers, 258, Symmetric card authentication key, 512, Symmetric cipher model, 86–91, ciphertext, 87, cryptanalysis and brute-force attack,, 89–91, attacks on encrypted messages, 90, computationally secure encryption, scheme, 91, cryptanalysis, 89, unconditionally secure encryption, scheme, 91, cryptography, keys used, 89, plaintext, processed, 89, plaintext to ciphertext, 89, decryption algorithm, 87, encryption algorithm, 86, model of symmetric cryptosystem, 88, plaintext, 86, secret key, 86, secure use of conventional encryption,, 87, simplified model of symmetric, encryption, 87, Symmetric cryptosystem, 88, Symmetric encryption, 20, 86–91,, 384–387, external error control, 386, internal error control, 386, remote user-authentication using, mutual authentication, 478–481, one-way authentication, 482, Symmetric key encryption, 89, 687, System integrity, 22, , T, , Tag, 391, 656, TDEA. See Triple Data Encryption, Algorithm (TDEA), Temporal Key Integrity Protocol, (TKIP), 607–608, Text type, 621, TFC. See Traffic flow confidentiality, (TFC), Theta step function, 371–373, Threats, mobile device security, 586–587, interaction with other systems, 587, lack of physical security controls,, 586, location services, 587, by unknown parties, 587, untrusted content, 587, untrusted mobile devices, 586, untrusted networks, 587, wireless network security, 583–584, Ticket, 485, Ticket-granting server (TGS), 486, Ticket-granting service exchange, 497, Time complexity, 291, 293, Timestamp, 424, 477, Timing attacks, 302, 305–306, blinding, 306, constant exponentiation time, 306, DES, 135, random delay, 306, TKIP. See Temporal Key Integrity, Protocol (TKIP), TKIP sequence counter (TSC), 608, Total break, 423, Traditional block cipher structure,, 119–129, arbitrary reversible substitution, cipher, 122, block cipher, 120–121, confusion, 124–125, diffusion, 124–125, encryption and decryption tables for, substitution, 122, Feistel cipher, 123–129, block size, 126, ease of analysis, 127, fast software encryption/decryption,, 127, key size, 127, number of rounds, 127, round function, 127, structure, 121–123, 125–127, subkey generation algorithm, 127, ideal block cipher, 121–123, motivation for Feistel cipher structure,, 121–123, permutation, 123, 125, reversible or nonsingular, 121, round function, 125, SPN, 125, stream cipher, 120–121, substitution, 123, 125, Traffic analysis, 27, Traffic flow confidentiality (TFC), 675, Traffic padding, 33, Traffic processing, IP security (IPsec),, 671–673, inbound packets, 672–673, outbound packets, 671–672, Traffic security, 589, Traffic Selector payload, 692, Traffic-flow confidentiality, 30, Transfer encodings, 622–623, base64 transfer encoding, 623, quoted-printable, 623, Transformation functions, AES, 179–190, AddRoundKey transformation, forward add round key, transformation, 189, , 765, , inputs for single AES round, 190, inverse add round key, transformation, 189, MixColumns transformation, 186–189, forward mix column transformation,, 186, inverse mix column transformation,, 187, ShiftRows transformation, AES row and column operations, 186, forward shift row transformation, 185, inverse shift row transformation, 185, substitute bytes transformation, 180–185, AES byte-level operations, 180, constuction of S-Box and IS-Box, 182, forward substitute byte, transformation, 180, inverse substitute byte, transformation, 184, Transport layer protocol, host keys, 568–569, key generation, 572–573, packet exchange, 569–572, algorithm negotiation, 571, key exchange, 571, message authentication code, 570, packet length, 569, padding length, 569, payload, 569, random padding, 570, Transport Layer Security (TLS),, 546–578, alert protocol, 554–555, architecture, 549–551, cipher spec, 551, compression method, 551, connection, 550, is resumable, 551, master secret, 551, peer certificate, 550, session, 550, session identifier, 550, attacks, categories, 564–565, TLSv1.3, 565–566, Change Cipher Spec protocol, 553, connection state, client write key, 551, client write MAC secret, 551, initialization vectors, 551, sequence numbers, 551, server and client random, 551, server write key, 551, server write MAC secret, 551, cryptographic computations, 561–563, generation, 562–563, heartbeat protocol, 563–564, master secret creation, 561, handshake protocol, 556–561, HTTPS, 566–567, connection closure, 567, connection initiation, 566–567, message authentication code, 570, padding, 569, pseudorandom function, 562–563, record protocol, 551–553, compressed length (16 bits), 553, compression, 551–552, confidentiality, 551, content type (8 bits), 553, fragmentation, 551, MAC, 553, major version (8 bits), 553, message integrity, 551–553, minor version (8 bits), 553, secure shell, 567–578, connection protocol, 574–579, transport layer protocol, 568–572, user authentication protocol,, 573–574
Page 767 :
766, , INDEX, , Transport Layer Security (TLS), (Continued), session state, Cipher spec, 551, compression method, 551, is resumable, 551, master secret, 551, peer certificate, 550, session identifier, 550, web security considerations, 547–549, Transport modes, 666–668, 676–681, Transposition cipher, 107–108, Trap-door one-way function, 293, Triple Data Encryption Algorithm, (TDEA), 124, Triple Data Encryption Standard, (3DES), known-plaintext attack on, 212, with three keys, 213, with two keys, 210–213, True random number generator, (TRNG), 253–255, 271–279, block cipher, 274, entropy sources, 271–272, disk drives, 271–272, sound/video input, 271, hash function, 273–274, health testing, 274–276, on conditioning function, 276, on noise source, 274–276, Intel digital random number, generator, 276–279, hardware architecture, 277–278, logical structure, 278–279, PRNGs vs., 254, Trusted functionality, 32, TSC. See TKIP sequence counter (TSC), Tunnel modes, 574, 666–668, 676–681, Tweakable block ciphers, 225–226, Two simple hash function, 346–348, Typewriter correction ribbon, 110, , U, , Unconditionally secure encryption, scheme, 91, Uniform distribution, 252, Uniformity, 255, Universal forgery, 423, Unpredictability, 253, backward, 256, forward, 256, Update function, 266–267, U.S. National Security Agency (NSA),, 336, Use of known authenticated session, 40, User authentication, federated identity management, identity federation, 504–508, identity management, 503–504, Kerberos, 482–500, motivation, 483–484, Version 4, 484–494, Version 5, 495–500, personal identity verification, authentication, 512–514, credentials and keys, 511–512, documentation, 510–511, system model, 509–510, remote user-authentication principles, identification step, 474, mutual authentication, 477–478, , Hiva-Network.Com, , NIST model, 475–476, one-way authentication, 478, something the individual does, (dynamic biometrics), 476, something the individual is (static, biometrics), 476, something the individual knows, 476, something the individual possesses,, 476, verification step, 474, using asymmetric encryption, mutual authentication, 500–501, one-way authentication, 501–502, using symmetric encryption, mutual authentication, 478–481, one-way authentication, 482, User Authentication Protocol, authentication methods, 574, message exchange, 573–574, message types and formats, 573, User credential compromise, 40, User credential guessing, 40, User terminal and user (UT/U), 40, , V, , Vendor ID payload, 692, Verifier, 476, Vernam cipher, 104–105, Vigenère cipher, 102–104, Virtual local area networks (VLANs),, 522, Virtual private networks (VPNs), 589,, 677, Virus detection, 345, Viruses, 43, , W, , Weak collision resistant, 349, Web security, 543, considerations, 547–549, threats, 548, traffic security approaches, 548–549, Weierstrass equation, 323, WEP. See Wired Equivalent Privacy, (WEP), Wi-Fi, 582, Wi-Fi Protected Access (WPA), 590, 596, Wired Equivalent Privacy (WEP), 596,, 607, Wireless network security, 582–609, components, 583, IEEE 802.11 wireless LAN, 589–595, association-related services, 594–595, MPDU format, 592, network components and, architectural model, 592–593, protocol architecture, 590–592, services, 593–595, terminology, 590, Wi-Fi alliance, 590, IEEE 802.11i wireless LAN security,, 595–609, authentication phase, 601–603, discovery phase, 599–601, elements of, 597, key management phase, 603–607, phases of operation, 596–599, protected data transfer phase,, 607–608, pseudorandom function, 608–609, services, 596, , measures, 584–585, securing wireless access points, 584, securing wireless networks, 585, securing wireless transmissions, 584, mobile device security, 585–589, strategy, 587–589, threats, 586–587, threats, 583–584, wireless security, 582–585, Worms, 43, WPA. See Wi-Fi Protected Access, (WPA), Writing Across the Curriculum (WAC), movement, 701, WS-Security, 506, , X, , X.509 certificates, 459–467, certificate subject and issuer attributes, issuer alternative name, 466, subject alternative name, 466, subject directory attributes, 466, certification authority, forward certificates, 463, reverse certificates, 463, certification path constraints, basic constraints, 467, name constraints, 467, policy constraints, 467, formats, extensions, 461, issuer name, 461, issuer unique identifier, 461, period of validity, 461, serial number, 460, signature, 461, signature algorithm identifier, 460, subject name, 461, subject unique identifier, 461, subject’s public-key information,, 461, version, 460, hierarchy, 464, key and policy information, 465–466, authority key identifier, 466, certificate policies, 466, key usage, 466, policy mappings, 466, private-key usage period, 466, subject key identifier, 466, revocation of, 464–465, user’s, 462–464, Version 3, 465, XML. See Extensible Markup Language, (XML), XTS-AES mode, 224–231, ciphertext-stealing technique, 229, definition, 230, feedback characteristic of modes of, operation, 225, operation on sector, 229–231, operation on single block, 227–229, storage encryption requirements,, 226–227, tweakable block ciphers, 225–226, , Z, , Zero point, 323, ZIP, 94
