Java Security

Java Security ™ This page intentionally left blank Java Security ™ Harpreet Sethi with ©2002 by Premier Press, a...

Author: Harpreet Sethi

880 downloads 1707 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Java Security ™

This page intentionally left blank

Java Security ™

Harpreet Sethi with

©2002 by Premier Press, a division of Course Technology. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system without written permission from Premier Press, except for the inclusion of brief quotations in a review. The Premier Press logo and related trade dress are trademarks of Premier Press, Inc. and may not be used without written permission. Sun, Sun Microsystems, the Sun Logo, Solaris, Java, and the Jini logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners. Important: Premier Press cannot provide software support. Please contact the appropriate software manufacturer’s technical support line or Web site for assistance. Premier Press and the author have attempted throughout this book to distinguish proprietary trademarks from descriptive terms by following the capitalization style used by the manufacturer. Information contained in this book has been obtained by Premier Press from sources believed to be reliable. However, because of the possibility of human or mechanical error by our sources, Premier Press, or others, the Publisher does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from use of such information. Readers should be particularly aware of the fact that the Internet is an ever-changing entity. Some facts may have changed since this book went to press. ISBN: 1-931841-85-3 Library of Congress Catalog Card Number: 2002106529 Printed in the United States of America 02 03 04 05 BH 10 9 8 7 6 5 4 3 2 1 Premier Press, a division of Course Technology 2645 Erie Avenue, Suite 41 Cincinnati, Ohio 45208

Publisher Stacy L. Hiquet Marketing Manager Heather Hurley Managing Editor Sandy Doell Project Editor/Copy Editor Kezia Endsley Technical Reviewer NIIT Interior Layout Marian Hartsough Associates Editorial Assistants Margaret Bauer Elizabeth Barrett Indexer Tom Dinse Cover Designer Mike Tanamachi

About NIIT NIIT is a global IT solutions corporation with a presence in 38 countries. With its unique business model and technology-creation capabilities, NIIT delivers software and learning solutions to more than 1,000 clients across the world. The success of NIIT’s training solutions lies in its unique approach to education. NIIT’s Knowledge Solutions Business conceives, researches, and develops all of its course material. A rigorous instructional design methodology is followed to create engaging and compelling course content. NIIT trains over 200,000 executives and learners each year in information technology areas using stand-up training, video-aided instruction, computer-based training (CBT), and Internet-based training (IBT). NIIT has been featured in the Guinness Book of World Records for the largest number of learners trained in one year! NIIT has developed over 10,000 hours of instructor-led training (ILT) and over 3,000 hours of Internet-based training and computer-based training. IDC ranked NIIT among the Top 15 IT training providers globally for the year 2000. Through the innovative use of training methods and its commitment to research and development, NIIT has been in the forefront of computer education and training for the past 20 years. Quality has been the prime focus at NIIT. Most of the processes are ISO-9001 certified. It was the 12th company in the world to be assessed at Level 5 of SEI-CMM. NIIT’s Content (Learning Material) Development facility is the first in the world to be assessed at this highest maturity level. NIIT has strategic partnerships with companies such as Computer Associates, IBM, Microsoft, Oracle, and Sun Microsystems.

Acknowledgments My husband and my parents have been a strong support to me while I worked at long hours to complete this book. They really helped me bring out the best in the book. I thank them all for their support. My project manager, Anita Sastry, has worked meticulously reviewing and giving here valuable inputs to the book. Without her help, the book would not have been in its present form. Thank you Kezia Endsley for editing the book so well. Your valuable inputs on the book make it a wonderful book! I would also like to thank Stacy Hiquet for making this book happen at the first place! She has provided active support in all development stages of the book. My special thanks also go out to Pallavi Jain for helping me out with reviews of the book and giving valuable inputs for improving the quality of the book.

About the Author HARPREET SETHI has worked at NIIT since 1999 as a technical trainer, technical writer, instructional designer, and an ID reviewer. She has two years of experience in teaching various career programs at NIIT’s Career Education Group division. Harpreet has taught various technical subject areas, including Java, C, C++, HTML, UML, Networking Essentials, SQL Server 6.5, Unix, Microsoft Windows NT Server 4.0, Windows 95, Windows 98, and Microsoft Office 97 and 2000. Harpreet has worked extensively as an instructional designer and as a developer with NIIT’s Knowledge Solutions Business division to develop and review instructor-led training (ILT) products for various software and technologies. These include Java Programming Essentials, Macromedia Dreamweaver 2.0, 3.0, and 4.0, Microsoft Office 2000, Microsoft Office XP, Adobe Photoshop 6.0, and StarOffice 5.1. She has worked on projects for various U.S.-based clients on these technologies.

Contents at a Glance Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

PART I

PART II

INTRODUCTION TO JAVA SECURITY . . . . . . . . . 1 1

Security: An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2

Java Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3

The Java Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4

Class Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ADVANCED JAVA SECURITY CONCEPTS . . . . . 91 5

The Class Loader and the Class File Verifier . . . . . . . . . . . . . 93

6

Java 2 Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7

The Access Controller and Permissions in Java 2 . . . . . . . . . 145

8

Security Configuration Files and Security APIs . . . . . . . . . . 171

9

An Introduction to Java 2 Security Tools . . . . . . . . . . . . . . . 201

10

An Introduction to Java Plug-ins . . . . . . . . . . . . . . . . . . . . . 235

11

Message Digests and Digital Signatures. . . . . . . . . . . . . . . . 259

12

An Introduction to Crypography . . . . . . . . . . . . . . . . . . . . . 297

13

Introduction to Java Authentication and Authorization Service ( JAAS) . . . . . . . . . . . . . . . . . . . 321

14

Java and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

15

Java and SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Contents at a Glance

PART III APPENDIXES . . . . . . . . . . . . . . . . . . . . . . . 381 A

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

B

FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

C

In the Wings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

ix

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . xix

PART I

INTRODUCTION TO JAVA SECURITY 1

Chapter 1

Security: An Overview . . . . . . . . . . . . . . . . . . . . 3 The Need for Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Java Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 An Overview of the Development Environment . . . . . . . . . . . . . . . . 5 An Overview of the Execution Environment. . . . . . . . . . . . . . . . . . . 8 Java Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 An Overview of Java and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Java Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Java Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Java Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Limitations of Java Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Java 2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Java 2 Applet Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Using the Policy Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Java 2 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Java 2 and Crypography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Cryptographic Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Cryptographic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Rules for Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Contents

Chapter 2

Java Security Model. . . . . . . . . . . . . . . . . . . . . 35 Java Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 History of Java Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 The Sandbox Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 The Trusted Code Security Model . . . . . . . . . . . . . . . . . . . . . . . . . 38 Java 2 Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Protection and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Description of a Policy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Protection Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Classes in Java 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 The Extensions Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Application Class Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 System Class Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Java 2 Class Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Working of the SecureClassLoader Class . . . . . . . . . . . . . . . . . . . . 47 Resource Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Policy Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Grant Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Default System Policy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Managing Security in Java 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 User-Defined Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 3

The Java Virtual Machine . . . . . . . . . . . . . . . . . 57 JVM Safety Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 The JVM Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 The Class Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 The Class File Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 The JVM Heap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 The Method Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 The Native Method Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Just-in-Time ( JIT) Compilers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

xi

xii

Contents

The JVM Execution Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 The Security Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapter 4

Class Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 The Compilation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 The Class File Format in Java 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 The Constant Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Decompilation Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Preventing Decompilation Threats . . . . . . . . . . . . . . . . . . . . . . . . . 80 Java Bytecode: Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Type Safety. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

PART II ADVANCED JAVA SECURITY CONCEPTS . . . . . . . . . . . . . . . . 91 Chapter 5

The Class Loader and the Class File Verifier . . . . 93 Class Loaders: Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 The Class Loader Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 The Class-Loading Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 The Parent-Delegation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 User-Defined Class Loaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Creating a Java 1.1 User-Defined Class Loader . . . . . . . . . . . . . . . 102 Creating a Java 1.2 User-Defined Class Loader . . . . . . . . . . . . . . . 108 The Class File Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Pass One: Internal Structure Checks for Class Files. . . . . . . . . . . . 112 Pass Two: Class File Semantic Checks. . . . . . . . . . . . . . . . . . . . . . 112 Pass Three: Bytecode Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Pass Four: Symbolic Reference Check . . . . . . . . . . . . . . . . . . . . . . 115

Contents

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Chapter 6

Java 2 Security Manager . . . . . . . . . . . . . . . . 121 The SecurityManager Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Network Operations Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 File System Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Thread Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Package and Class Access Checks . . . . . . . . . . . . . . . . . . . . . . . . . 126 Operating System Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 JVM Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Security Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 How the Security Manager Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Areas Not Controlled by the Security Manager . . . . . . . . . . . . . . . 131 Cycle Stealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Forging E-Mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Writing Your Customized Security Manager . . . . . . . . . . . . . . . . . . . . 135 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 7

The Access Controller and Permissions in Java 2. . . . . . . . . . . . . . . . . . . 145 The AccessController Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Methods of the AccessController Class . . . . . . . . . . . . . . . . . . . . . 147 Writing Privileged Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Permissions in Java 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Built-in Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Permission Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Custom Permission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

xiii

xiv

Contents

Chapter 8

Security Configuration Files and Security APIs . . . . . . . . . . . . . . . . . . . . . 171 The Security Properties File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Security Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Policy Providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Policy File URL Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Policy File Property Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Specifying an Additional Policy File . . . . . . . . . . . . . . . . . . . . . . . 178 Policy Identity Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 The Keystore Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 System Identity Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Checking Package Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Checking the Package Definition . . . . . . . . . . . . . . . . . . . . . . . . . 180 The Security Policy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Keystore Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Grant Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 The caceerts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Java 2 Security APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 The java.security Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 The java.security.spec Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The java.security.cert Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 The java.security.interface Package . . . . . . . . . . . . . . . . . . . . . . . . 196 The java.security.acl Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Chapter 9

An Introduction to Java 2 Security Tools . . . . . 201 The keytool Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 The keytool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Use of the keytool Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 The jar Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Creating JAR Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Viewing the Contents of JAR Files . . . . . . . . . . . . . . . . . . . . . . . . 216 Extracting the Contents of JAR Files . . . . . . . . . . . . . . . . . . . . . . 218

Contents

Updating JAR Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Running the Software Packaged in JAR Files . . . . . . . . . . . . . . . . 219 The jarsigner Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Contents of Signed JAR Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Options Associated with the jarsigner Tool . . . . . . . . . . . . . . . . . . 222 Use of the jarsigner Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Chapter 10 An Introduction to Java Plug-ins . . . . . . . . . . . 235 The Features of the Java Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Installing the Java Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 The Role of the Java Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Modifying HTML Code for Java Plug-in Support. . . . . . . . . . . . . . . . 239 Changes for Netscape Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Changes for Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Changes for Both Netscape Navigator and Internet Explorer . . . . . 242 Changes for All the Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 The HTML Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Security and the Java Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Applets and Java Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 The Java Plug-in Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 The Basic Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 The Advanced Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 The Proxies Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 The Cache Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Chapter 11 Message Digests and Digital Signatures . . . . . 259 Message Digests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Classes and Interfaces for Message Digests . . . . . . . . . . . . . . . . . . 261 Message Authentication Codes (MACs) . . . . . . . . . . . . . . . . . . . . 275

xv

xvi

Contents

Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Classes and Interfaces for Digital Signatures . . . . . . . . . . . . . . . . . 281 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Chapter 12 An Introduction to Crypography. . . . . . . . . . . . 297 The Need for Crypography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Symmetric Key Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Asymmetric Key Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Java Crypography Architecture ( JCA) Cryptographic Engines and Algorithms. . . . . . . . . . . . . . . . . . . . . 302 Cryptographic Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Java Cryptography Extension ( JCE). . . . . . . . . . . . . . . . . . . . . . . . . . . 305 The javax.crypto.Cipher Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 The javax.crypto.KeyAgreement Class . . . . . . . . . . . . . . . . . . . . . . 310 The javax.crypto.KeyGenerator Class . . . . . . . . . . . . . . . . . . . . . . 311 The javax.crypto.SealedObject Class . . . . . . . . . . . . . . . . . . . . . . . 311 The Secret Key Classes and Interfaces . . . . . . . . . . . . . . . . . . . . . . 312 Provider and Algorithm Independence in JCE. . . . . . . . . . . . . . . . 312 Creating Your Own Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Chapter 13 Introduction to Java Authentication and Authorization Service (JAAS) . . . . . . . . . . 321 An Overview of JAAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Core JAAS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 The Subject Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 JAAS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 JAAS Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Contents

JAAS Settings in the java.security File . . . . . . . . . . . . . . . . . . . . . . . . . 335 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Chapter 14 Java and Firewalls . . . . . . . . . . . . . . . . . . . . . 341 An Introduction to Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 The Interaction of Programs through Firewalls . . . . . . . . . . . . . . . 343 Downloading an Applet from a Remote Server . . . . . . . . . . . . . . . . . . 346 Java Network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Creating Java Application that Work through Firewalls . . . . . . . . . 348 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Chapter 15 Java and SSL. . . . . . . . . . . . . . . . . . . . . . . . . 355 An Overview of SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 The SSL Handshake. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 SSL Support in Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 An Overview of Java Secure Socket Extension ( JSSE) . . . . . . . . . . . . . 359 The javax.net Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 The javax.net.ssl Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 The javax.security.cert Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Using Java and SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 JSSE Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 SSL Server Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 SSL Client Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 The SSLSession Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 The SSLSessionContext Interface . . . . . . . . . . . . . . . . . . . . . . . . . 376 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

xvii

xviii

Contents

PART III APPENDIXES . . . . . . . . . . . . . . 381 Appendix A Best Practices . . . . . . . . . . . . . . . . . . . . . . . 383 Limiting Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Handling Static Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Avoiding Dependencies on Package Scope . . . . . . . . . . . . . . . . . . . . . . 384 Declaring Final Classes or Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Avoiding Writing Privileged Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Avoiding the Cloneable Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Avoiding Storing Secrets in Your Code . . . . . . . . . . . . . . . . . . . . . . . . 385 Avoiding Comparing Classes by Name. . . . . . . . . . . . . . . . . . . . . . . . . 386 Avoiding Mix-and-Match Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Appendix B FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Appendix C In the Wings . . . . . . . . . . . . . . . . . . . . . . . . . 391 The Future of Java Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 The Java Protected Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Secure Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Table-based Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Domain Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Introduction This book provides you with comprehensive knowledge about Java security. It is aimed at readers who are proficient in Java. This book is intended for Web application developers, whose job profile includes setting up security, monitoring, security maintenance, and other advanced management and maintenance tasks. This book will be of immense help for both novice and experienced developers who want to efficiently handle their role. It is for anyone who wants to create secure Java applications or applets. This book includes detailed explanatory concepts, hands-on exercises, and questions to check your understanding, at the end of each chapter. This book has three parts. The first part covers the basic Java security features. This part starts off with a general overview and need for Java security. The book covers a comparison of the Java 2 security model with the security model for earlier versions. JVM architecture and security features are discussed next, in this book. This part also covers the vulnerabilities of Java class file format. The second part covers the advanced Java security features. This part covers the various security components, such as class loader, class file verifier, and security manager in detail. The various Java 2 security tools, such as keytool, jar, jarsigner, and Policy tool are also discussed. This part also introduces the concept of cryptography. The cryptographic features in Java are supported by the Java Cryptography Architecture ( JCA) and Java Cryptography Extension ( JCE). The Java Authentication and Authorization Service ( JAAS) is discussed later in the book. Apart from the chapters, this book also includes another section containing the appendixes. The appendixes include FAQs and tips and tricks that give you real-life advice about Java security. This section also covers the future of Java security in further releases of Java. Although the Java 2 security model is comprehensive, it still needs to be improved to avoid implementation errors caused due to the presence of security loopholes.

How to Use This Book This book has been organized to facilitate a better grasp of content covered in the book. The various conventions used in the book include the following: ◆ Notes. Notes give additional information that may be of interest to the

reader, but it is not essential to performing the task at hand.

xx

Introduction ◆ Cautions. Cautions are used to warn users of possible disastrous results if

they perform a task incorrectly. ◆ A “Check Your Understanding” section at the end of each chapter. These

sections contain multiple choice and short answer questions that help you review the material discussed in that chapter as well as determine whether you understand the material well enough to proceed.

PART

I

Introduction to Java Security


Chapter 1 Security: An Overview

I

n this chapter, I’ll discuss the importance of security while downloading executable content from the Web. The chapter starts with a brief introduction of the Java development and execution environment. I’ll also discuss the Java security features as well as the limitations in Java security. The security implementation in applets and applications will also be discussed. The big question is why all this hype about security; why is security implementation necessary while designing applications? The next section discusses the need for security.

The Need for Security The Internet has become a major business platform for various companies and organizations. Companies have attributed their growth rate to the Internet, which acts as a platform for marketing, sales, advertising, providing services, and customer support. However, the Internet brings with it certain risks as well. There are times when a Web server is taken over or the private data submitted to a site is distributed across malicious sites. Firewalls are violated, and viruses are sent across networks, leading to the disruption of network operations. Therefore, if it is necessary for the Web platform to survive in the current business scenario, it is important to use this platform securely. Java, being the programming language for the Web, is also expected to impart security to Web applications. With the new and emerging technologies in the current scenario, the security aspect continues to be ignored in the initial phases of development. This is in contrast to Java, in which security is the primary design goal. I consider that fortunate because Java is primarily being used to design Web applications and applets. Although the initial Java security model was quite simple, there have been various evolutionary enhancements to this model. Therefore, if you wish to design distributed and secure Web applications, Java is the way to go. However, acquiring high-level security is not all that easy considering the fact that we hear about security threats every second day. High-level security requires elaborate planning, a structured design, strong architecture, and picture-perfect implementation. All these prerequisites form a part of the Java 2 platform and you will be reading about most of them in this book. Moreover, Java requires a security-oriented development and execution environment. Therefore, in the next section, I will discuss the development and execution environment of Java 2 before going into the intricacies of Java security.

SECURITY: AN OVERVIEW

Chapter 1

Java Fundamentals Java is composed of three components, namely, the development environment, the execution environment, and the interfaces. The Java 2 SDK has a lot more to offer than other programming languages. The SDK contains the necessary code and tools to compile, debug, and execute your Java programs. In addition, it supports the architecture for networking, file I/O, and creating GUI applications. These features of Java comprise the development environment. The Java Virtual Machine ( JVM) implements the execution environment of Java. Java programs can be executed on any platform, but the execution environment should be JVM-enabled. Therefore, it is because of the JVM that Java programs need not be rewritten if they are to be implemented on different platforms. The JVM is also responsible for security implementation. The JVM is a part of the Java Runtime Environment ( JRE), which also contains the Java core classes. The JRE exclusively contains runtime components such as the JVM and the core Java classes. It does not contain any development tools such as the compiler or the debugger. Java requires interfaces to interact with non-Java applications. These interfaces might have a simple or complex architecture. For example, you need the JDBC interface to connect to a relational database from a Java application. An interface can be used to serve as a protocol and can be implemented by any class anywhere irrespective of the class hierarchy. Interfaces are used when you don’t need to build a relationship between unrelated classes, although you do need to share the similarities between classes. Interfaces are used to identify the methods that classes could implement. The subsequent sections will cover these components in detail.

An Overview of the Development Environment Once you have written the Java source code, you need to compile it. Java both compiles and interprets the source code. The Java source code is compiled by using the javac compiler. After the Java source code is compiled, it is converted to bytecode, which is a platform-independent format. This is in contrast to other high-level languages in which the source code is compiled and converted to the machine language format. Now, the bytecode is interpreted by the interpreter, which is a part of the JVM. Java is an object-oriented language. Therefore, the Java source code consists of classes containing data and methods. When the source code is compiled into bytecode, the resulting class file will contain only those methods and classes, which are specified in the class definition. In addition, the source code contains calls to the methods of different classes. These classes are dynamically loaded by the JVM during runtime. This

5

6

Part I

INTRODUCTION TO JAVA SECURITY

is called dynamic linking. Therefore, while the program is running, the JVM builds an interconnection between the different classes and interfaces being used in the program. The system classes in Java are arranged in the form of packages. Packages are collections of related classes. You can also create your own packages containing classes that are derived from the Java basic classes. Next, you can control access to the members of a class through other objects. This is necessary to impart security to secret information or the data stored in classes. There are access levels specified in Java to regulate the access control on the members of a class. These access levels are mainly of three types: public, private, and protected. They are implemented by declaring fields or methods of classes by using the public, private, and protected keywords. The keywords are discussed as follows: ◆ The most secure access is provided by the private keyword. The class

members defined by using this keyword are accessible only from within the class that contains them. Therefore, private members are reserved only for the class that contains them and cannot be accessed by other classes. ◆ The next access level specifier is protected. The class members defined by using the protected keyword are accessible by the class that contains them,

the subclasses, and the remaining classes in the package. Therefore, protected members can be used by related classes such as the subclasses of the class that contains these protected members. However, unrelated classes cannot use them. ◆ The class members marked with the public access level specifier can be

accessed by any class irrespective of the package in which they are contained. You should be careful while declaring class members as public. Only those members that do not affect the running program by affecting the state of the object should be declared as public. The Java development environment also comprises Visual Application Builders (VABs) and Java beans. The next section covers these concepts in detail.

Java Beans The primary use of Java beans is that they facilitate the creation of visual applications. You might have used application builders such as Visual Basic, Visual Age, or Delphi. The main purpose of using application builders is that they reduce the code complexity. They also reduce the code needed for the application core, which is used for linking components. Therefore, VABs are used to build complex applications through the linking of predefined components. The advantage of using these builders is that you need not write complex code for your application. All you need to do is pick up a component with the desired functionality and plug it with the application. A Java


Chapter 1

bean is a reusable software component that can be modified by using the Visual builder tools. Reusable software components can be compared to the reusable parts used in other industries. For example, the electronic components of the circuit boards or car parts that can be reused across various car models are reusable components. Toolkits, calendars, and button sets are examples of reusable components in the software industry. Reusable components can act as standard interfaces for builder tools. Reusable components such as Java beans support a design-time interface, which allows builder tools to know the properties and events supported by the Java beans components. The attributes and behaviors of Java beans are marked through signature patterns that are referred to by the application construction tools. However, the use of Java beans is not limited to these tools because the signature patterns are recognizable through human readers and other application builder tools as well. Therefore, a Java bean is a component that consists of Java classes and performs a specific function. Although Java beans vary in functionality, they support certain basic features that are stated here: ◆ Java beans support signatures that allow a builder tool to examine the func-

tionality of the specified bean. This process is also referred to as introspection. ◆ The properties and behaviors of Java beans can be customized or modified

as per the user need. This process is also referred to as customization. ◆ The properties of Java beans can be modified or set programmatically while

either designing the application or running it. ◆ Java beans fire events, thereby informing the builder tools about their func-

tionality. ◆ Java beans support persistence, whereby the beans are customized and their

changed state is saved and reloaded later. Therefore, Java beans are reusable components that can be used within applications and customized as per your need. However, they affect the security aspect of your application because your application now contains code that is not being written directly by you. For this reason, you need to be sure that these components are from a trusted source before using them in your applications. The Java development environment also consists of security tools to handle security in your applications. The next section gives a brief introduction of these tools.

Java 2 Security Tools The Java 2 SDK supports various security tools to implement security-related features. These are the jar, jarsigner, keytool, and Policy tools. Except the Policy tool, which has a GUI interface, the remaining three are command-line tools. The jar

7

8

Part I


tool was also available in jdk1.1. The tools, jarsigner and keytool, replace the javakey tool of jdk1.1. These two tools provide more security features than the javakey tool. They password-protect the keystore and the private keys and generate and verify signed Java ARchive ( JAR) files. ◆ The jar tool is used to create JAR files. The JAR file format can be com-

pared to a ZIP file format. Multiple files such as class files are stored in a single archive file. To digitally sign code, the jar tool is used to place the code in a JAR file and the jarsigner tool is used to sign this file. ◆ The jarsigner tool is used to sign JAR files and verify the signatures on

JAR files. The tool refers to the keystore to find the private key and the associated certificates for signing the JAR files. The keystore is created by using keytool. Because the keystore and the private keys are password protected, the jarsigner tool prompts for passwords when accessing them. ◆ The keytool is used to manage the keystores. A keystore is a protected data-

base that contains the keys and certificates for a particular enterprise. Access to the keystore and the private keys is password protected. The keytool is used to create public and private key pairs, issue certificate requests, fetch replies from these requests, and assign the public keys of other parties as trusted. You will read more about these tools in Chapter 9, “An Introduction to the Java 2 Security Tools”. Let’s move on to the subsequent section, which discusses the execution environment in detail.

An Overview of the Execution Environment The execution environment of Java mainly comprises of the JVM. You are already aware that the Java source code is both compiled and interpreted. After compilation, the Java source code is converted to bytecode, which is further interpreted by the JVM. Therefore, the JVM converts the bytecode to the machine language code while executing the Java program. The execution time for a Java program is faster than that of other interpreted programs because the JVM interprets bytecode, which is nearly in the machine language format. The Java source code is compiled only once, whereas it is interpreted every time the Java program is executed. However, the JVM implementation does not result in high performance. The Just In Time (JIT) compilation is used to implement the JVM, and thereby, increase the performance of Java programs. In the JIT compilation, the interpretation part is ignored and the bytecode is directly converted to optimized machine code and executed directly. This results in faster execution time. Therefore, JIT compilation removes the overhead of interpretation.


Chapter 1

Besides the interpretation of bytecode, the JVM also implements security in Java applications. Before interpretation, the environment in which the program will execute is set by the JVM. Security implementation is mainly handled at this time. It is handled by three components, namely the class loader, the class file verifier, and the security manager. The subsequent sections discuss the role of these components in detail.

The Class Loader Dynamic class loading is an important feature of the JVM because it provides the capability of loading components at runtime. The class loader is one of the key components in the JVM. A class loader is a Java class with a specified functionality. It is responsible for the effective loading of the Java class bytecode into the runtime environment. The class loader primarily performs four tasks: ◆ It loads the Java class bytecode from an input stream, namely a file or a net-

work location. ◆ It invokes the bytecode verifier to verify the loaded class bytecode. ◆ It then invokes the access controller and security manager to confirm the

access permissions to the resources. ◆ Finally, it passes the classes to the JRE.

In the JRE, things may not be totally under your control, because the source from where the class bytecode is loaded can vary. Therefore, the class loader plays an important role in implementing security by fetching class files and creating a class object based on the access control permissions specified in the security policy file. Programmers can also specify their own class loaders that identify the location from where the classes are loaded and assign security permissions to them as per the requirement. An application can have multiple instances of ClassLoader objects, each for a specific class type. Alternatively, applets cannot create customized class loaders. However, a browser can load multiple applets for different Web pages using separate class loaders. These applet classes are treated distinctly by the JVM. The root of the class loader class hierarchy is the java.lang.ClassLoader class. This class was present in jdk1.0. However, in Java 2, a subclass of the abstract ClassLoader class is created, SecureClassLoader. The SecureClassLoader class further implements security by determining the access permissions for the class in the client system. You will read more about class loaders and their functionality in Chapter 5, “The Class Loader and the Class File Verifier”. Let’s move on to the next section, which discusses the class file verifier.

9

10

Part I


The Class File Verifier Before the class loader loads the specified class into the JRE, it passes the loaded bytecode to the class file verifier, which is also known as the bytecode verifier. You might be wondering why the bytecode generated by the Java compiler needs to go through a verification phase before being loaded to the JRE. This is because of the concept of trusted and untrusted classes. All the classes belonging to the Java core and those installed on the local system are trusted classes and, hence, need not be verified before execution. The remaining classes that are referenced by the concerned class are untrusted and need to be checked by the bytecode verifier. It is the task of the class loader to, in turn, fetch these classes for the execution of the Java program. Let’s run through the entire process once again. The JVM loads classes during runtime, the default class loader loads the core and local classes (the trusted classes), the referenced classes (the untrusted classes) are fetched from the specific URLs, and these external classes need to be verified by the class file verifier. This verification is necessary for confirming that only secure and valid code is executed. The untrusted code is checked before execution, resulting in uninterrupted execution of Java programs. Therefore, the role of the class file verifier is important for security implementation in the system. Figure 1-1 depicts this process. A class file verifier works in two distinct phases. The first phase is after the class is loaded, when the class file verifier checks the internal integrity of the bytecode and structure of the class files. In the second phase, when the bytecode is actually executed, the class file verifier checks the existence of the referenced classes in the respective code.

FIGURE 1-1 Role of the class file verifier


Chapter 1

You will read more about class file verifiers and their functionality in Chapter 5, “The Class Loader and the Class File Verifier”. Let’s move on to the next section, which discusses the security manager.

The Security Manager The security manager is also involved in the secure loading and execution of Java programs. The main task of the security manager is to judge whether access requests for valuable system resources are to be allowed. The security manager first considers the Java class requesting for the resource. The concerned Java class passes the control to the core Java classes, which, in turn, request for the resource. If the request is permitted, the program execution proceeds, otherwise java.lang.SecurityException is thrown. For every JVM implementation, only a single instance of the SecurityManager class can be created. The JVM can be so configured that the security manager is set before the first applet is loaded in the browser. This removes the possibility of the security manager being replaced by a malicious Java applet, which, in turn, replaces the security manager with its own security manager that has access permissions for valuable system resources. In earlier versions of Java, creating a customized security manager was not possible because these versions supported the SecurityManager class, which was an abstract class. However, in Java 2, the SecurityManager class is not abstract, and instances or subclasses of this class can be created in which methods can be added or replaced in the default SecurityManager class implementation. You will read more about the working of the security manager in Java 2 in Chapter 6, “Java 2 Security Manager”. Figure 1-2 depicts the role of the three components—the class loader, the class file verifier, and the security manager—in the execution environment. Now, as we have discussed the two components of Java, the development and the execution environment, let’s discuss the third component— interfaces.

Java Interfaces Java interfaces are used so that unrelated objects can interact with each other. Interfaces are nothing but behavior protocols that can be implemented by any class in the class hierarchy. Therefore, interfaces provide the facility of extending Java classes and interact with different types of applications. With the advent of Java technology and the increase in the complexity of Java projects, the need for such interaction has increased.

11

12

Part I


FIGURE 1-2 Components of the JVM in the execution environment

You can also extend Java by using methods written in some other programming languages. However, these methods do not provide the basic capabilities such as portability, security, and flexibility that are provided by the Java language and are ignored by a Java perfectionist. Java applets act as interfaces for client applications. However, these applications also need to interact with outdated systems for data and information. Therefore, with Java 2, there have been enhancements to the interfaces and architectures so that applications can be written purely in Java and yet interact with the outside world. The most used Java interfaces are JDBC, Remote Method Invocation (RMI), and Java beans. Let’s discuss these technologies with respect to the security loopholes in each of them.

JDBC JDBC provides connectivity to databases from Java applications or applets. You need to take care of the security implementation while providing access to a database through JDBC. Therefore, you should keep security in mind while designing server


Chapter 1

applications by providing limited access to the Java applets accessing the underlying database. Not all SQL queries should be allowed to execute on the database.

Remote Method Invocation (RMI) Remote Method Invocation (RMI) enables you to create distributed Java applications in which the methods of a remote Java object on a system can be called by another JVM on another system. However, there are security concerns when you deal with RMI. For example, when a server-side application communicates with a client-side applet for data that needs to be acquired through a database, the server-side application needs to verify the requests before giving access to the applet for the database.

Java Beans Java beans, as discussed previously, provide easier application development. They are also a useful aid in distributed application development. However, you need to be cautious of the security implementation, as is the case with the other interfaces discussed above. A malicious Java applet can access the trusted classes through the Java beans that provide access to particular executable files. Therefore, you need to be very careful when dealing with Java beans. Now, as I have discussed the basics of the Java environment, let’s discuss the security aspect of Java as well. The subsequent sections in this chapter will cover this important topic.

An Overview of Java and Security Java is a language for the Web and is used to design Web pages. The first Web pages created using Java contained just images and text. However, this was an advancement from the traditional way of presenting information. You had access to a large repository of data that could be accessed through the hyperlinks on a page. The only drawback was that for executable programs, you had to refer to the server. The Web interface was so designed that you filled up data in a page and the data was transmitted to the server where it was acted on by an executable program. There were animations or puzzles that made a Web page more exciting; however, they could not be successful if they were placed on the server for execution. Moreover, if the concerned program was placed on the server, there was a long time interval between the submission of a customer query and the result of the query being displayed on the Web page. Wouldn’t it be much easier and require less overhead if executable programs could be placed on the Web page itself? However, here comes the security factor. If programs are placed on Web pages, there is a risk of viruses being downloaded when

13

14

Part I


you load the specified Web page in the browser or execute the program on your computer. Second, if the program was created using a specific platform that is not supported by your system, the main benefit of the Web being platform-independent whereby you can run programs on any client is lost. This security aspect is generally ignored by most programming languages. It is generally assumed that applications written in the specific language will consider security in its implementation details. However, Sun considered security from the design stages. Therefore, Java has many more capabilities besides being just a programming language. Java is an object-oriented language. However, certain areas, such as pointers that are a part of most object-oriented languages, are avoided in Java. This is because pointers can be used by malicious code to access the restricted memory areas of a client system. The JVM is an aid towards security implementation in Java. The executable code downloaded to the system does not have access to the valuable system resources of the client system. The access requirements of the code are judged by the security policies, the protection domains, and the security managers. You will read about each one of these in later chapters of the book. Due to the features discussed previously, the concept of executable code seems real now. You may already be familiar with the fact that Java supports both applications and applets. The applications are loaded locally, and the applets are Java programs that are downloaded from the Web and are executed in the browser. In earlier versions of Java, the applications could access all the local resources of the system, whereas the applets were constrained to the sandbox. However, in Java 2, all the code is recognized by its source and the entities signing the code. Access to system resources is judged by the security policy. There is a default system policy; however, you can also create a security policy file that suits your requirements. You can actually decide which resource is needed by the program and to what extent by deciding the access permissions for the resource in the policy file.

Java Security Requirements You can further strengthen Java security by knowing the security loopholes well before and trying to fill them up. First, you need to understand the scope of security for the system as a whole. You need to judge the threshold of attack by a cracker. The course taken by the data in an application needs to be judged for any security loopholes. While downloading applets from the Internet or any shared network, you need to consider network and data protection. Moreover, the code needs to be authenticated for eligible users through digital signatures. Network protection can be controlled using firewalls and security policies, whereas for data protection, you can encrypt the data by using various data encryption techniques. You need to be clear about the sys-


Chapter 1

tem areas that are susceptible to attacks by crackers. You then need to strengthen these areas and secure them accordingly. Don’t panic! This may sound like a whole lot of groundwork on your part; however, Java 2 is here to help you out. The Java 2 security architecture has the capability to predetermine the areas that are to be acted on by the local or remote code. You can then control access to these areas by specifying permissions for them through security policy files, protection domains, and security managers. There may still be loopholes in the Java security implementation. These are generally reported by applet hunters, people downloading applets or professionals who wish to find the loopholes and close them. Therefore, the risk in Java security is reduced as and when these loopholes are found and closed. You need to respond to the implementers when you locate any loopholes in the security implementation of Java. Therefore, to implement high-level Java security, you need to install and review Java security continuously.

Java Security On the whole, the major differences between Java and C++ do not permit the implementation of malicious code either while designing or creating Java programs. The security aspect of Java is highlighted through the use of the JVM. The security of the JVM, in turn, is attributed to bytecode rather than the Java source code. Bytecode, being machine-independent, enables you to run the applet from any server. Therefore, the platform-independence and security aspects of the Java programming language can be attributed more to bytecode than the Java source code. Bytecode is derived from the compilation of the Java source code, or it can also be generated from other high-level languages. However, bytecode derived directly from high-level languages has limited security implementation and can be used by crackers to create programs directly in bytecode, which can be used to attack systems. Let’s discuss the various security benefits in Java in the next section.

Java Security Features Code distribution is another area where security can be at a risk. This is the case when applications need code running on both the server and client ends. For example, this occurs while interacting with a GUI or while connecting to the network using a remote caller. Such an open link can be a security loophole. Therefore, the system is susceptible to an attack through the intermediary placed between the client and the server. The role of this intermediary is to intercept the data flowing between the two

15

16

Part I


computers. So, unknowingly, while you are transferring data from the client to the server or vice versa and this data is passing through the intermediary, the cracker can attack the intermediary and the data can either be corrupted, changed, or infected with a virus. Therefore, code distribution between a client and a server can aid the tampering of the system. Therefore, instead of transferring code using an intermediary computer, you can do it through a physical medium such as a disk, by downloading code over a trusted network connection, or by using the Java security features. Java may not always be the fastest or the correct choice; however, Java code is much more secure than a normal download in the sense that it can be checked and verified through digital certificates and signatures. This does not hold true for the other possibilities in physical distribution. The three components of the JVM—namely, the class loader, the class file verifier, and the security manager—help to perform checks on the downloaded applets. You have already read about the role of each component in the preceding sections. The task of the class loader is to accumulate all the necessary resources for the execution of a Java program; a class file verifier checks and verifies the loaded code; and finally, the security manager dictates the access control permissions for system resources. Therefore, the security features of Java distinguish it from other programming languages. Java users can secure their systems from attacks that lead to system corruption. They do this through digital signatures and by using the three security components to validate the code. If you miss out these validation checks, you could end up crashing your system or being attacked by a virus. Now, let’s discuss the limitations of Java security in the next section.

Limitations of Java Security If the Java system is set up properly, there is no reason for security threats in the system. If implementation errors are avoided, the threats to Java security can be minimized. However, if something does go wrong in the implementation, the most tragic security threat is that of your system crashing due to attack of malicious applets. If you are connected to another computer via a network, there is a possibility of data being transferred to the other computer or a virus attack. Therefore, Java is designed to effectively combat these security threats and act as a savior. Java can also provide security against the invasion of highly secret business data. For example, imagine that your private key has been deciphered and used by crackers to digitally sign code or official documents using your identity. This is much worse than having to reinstall your system or rewrite your business data on the computer. Because Java is the only language in which security has been implemented right from the design stage, it offers a high level of security to remote executable programs. It is


Chapter 1

not that there are no security loopholes in Java. However, Java security professionals have taken it as a challenge to locate these loopholes in Java implementation and close them as soon as possible. However, there are still certain security threats that cannot be minimized even by using Java. An example of such a threat is cycle stealing. Imagine that you have downloaded a program and executed it on your computer. Now, instead of executing, it has blocked the major system resources and is wasting the CPU time of the client computer, thereby, preventing the actual operation of the program to be performed. Therefore, Java still has threats attached to its security implementation, although they are not a major problem for the client system. Now, let’s move on to discussing security in Java 2.

Java 2 Security Through the preceding sections, it might be clear that security implementation is now an important part of Java. This is true because Java is a language of the Web and needs to be secure. The Java security implementation has changed across the various version releases of Java. In jdk1.0, local code was granted access to all the system resources, whereas remote or downloaded code was allowed access to very limited resources. Therefore, the use of applets or downloaded code was limited to the enhancement of Web pages. In jdk1.0, local code was totally trusted and given access to all the system resources. In jdk1.1, developers had the option of digitally signing their code. Depending on these signatures, the user of the client computer could decide whether the downloaded code was from a trusted source. If the code belonged to a trusted source, it was given access to all the system resources. In other words, this trusted code was equated with the local code on the client computer. Alternatively, code that was not from a trusted source was subjected to limitations and could access only limited system resources. The only drawback in this model was that you could not control the permissions given to trusted signed code. For example, if you wanted to restrain the remote code from having write permission on a file, it was not possible because, by default, trusted remote code had write permission for all the files on the system. The remote code was automatically granted permissions to access, read, and write in the files and directories of the system or start a network connection. This limitation has been, however, controlled in the next version release, Java 2. In Java 2, you can further classify remote code on the basis of the source location of the code or the owners of the code who have digitally signed the code. You can regulate control over resource access depending on the URL location of the code and the

17

18

Part I


signers of the code. For example, a user can specify that the code signed by particular signers is to have only read access to a specific file on the system and that downloaded from a specific URL location can have write permission. These restrictions are not only for remote code. Even local code is subjected to them. Therefore, with careful understanding of the security threat, Java could easily pave its way through effective security implementation. You know that Java programs are of two types, applets and applications. The subsequent sections cover applet and application security in Java 2.

Java 2 Applet Security With the concept of executable programs being introduced on the Web, more emphasis should be paid to applet security as a whole. A minor security flaw in an executing applet can result in a system crash, a virus attack, or the disclosure of sensitive data in a database to crackers. Therefore, for users to effectively use applets, it is important to minimize these security threats. However, one cannot ignore the fact that increasing the security of applets curbs their capabilities. The Java 2 security model allows you to utilize the various capabilities of applets as well as maintain a high level of security. You are already familiar with the various security restrictions imposed across various versions. The most significant security feature introduced in Java 2 is the capability to specify security policies for both applets and applications. The Java 2 fine-grained access control model contains a configurable security policy that caters to both Web developers and users. Developers can provide applet capability to their users, and users can limit these capabilities depending on the trust level of the source location on the Java code. Therefore, the security model of jdk1.2 provides the least privileges for system resources. The security policy determines which resource access is permitted to an applet based on the source of the code and the identities of the signers of the code. You can specify certain policies in the security policy without programming. For example, you can grant permissions to any applet to listen to TCP ports greater than 1000 or you can grant the applets signed by Cod and John permission to write files into the temp directory on the hard disk.

Specifying a Security Policy for an Applet To specify a security policy for an applet, all you have to do is to edit the appropriate policy configuration file. You can do this in a number of ways, which are listed here: ◆ Set the value of the policy.java property to the name of the appropriate

security policy file.


Chapter 1

◆ Use the -D command-line option to set the value of the java.policy prop-

erty to a different security policy file. Consider the following code statement: java -Djava.policy = “try.policy” Trial

This code statement enables you to use the try.policy file while executing the Trial applet class. ◆ Create or edit the default system policy file located at \lib\security\java.policy where is the directory in which the default jdk1.2 installation is stored. When you edit the java.policy file, it applies to all

the users of the jdk1.2 installation. You will learn to compose a policy file in a subsequent section of the chapter. ◆ Finally, you can replace the class, java.security.PolicyFile, used to

implement the security policy with another class. This can be done by editing the java.security file. All you need to do is change policy.provider = java.security.PolicyFile

to policy.provider = Class1

where Class1 is the class name. When the bytecode is interpreted, it first loads the system policy and then acts on the user policy. The security policy file consists of entries called grant entries, which identify the code’s access permissions on various system resources. The permissions are granted based on the code source and the signers of the code. You will learn more about the security policy file and its entries in Chapter 2, “Java Security Model”.

Signing Applets When an organization or individual signs a specific applet, it indicates that the applet has been reviewed for all security defects. A digital signature attached to an applet acknowledges the fact that the signed code belongs to the specified organization signing the code and has been delivered to the user without any modifications. The organization signing the applet is also responsible in case of security attacks. If the signature is from a known organization, the user can also consider increasing the access level for the specified applet. You need to perform the following two steps to sign applets: ◆ Archive the class files of an applet in a JAR file by using the jar tool. ◆ Sign the JAR file by using the jarsigner tool.

The subsequent sections discuss these steps in detail.

19

20

Part I


Creating JAR Files To create JAR files, you first need to move to the directory containing the class files and then execute the jar command. For example, consider the following code statement: jar -cf classes.jar AccessFileApplet.class ReadFileApplet.class

This statement creates the classes.jar file, which contains the classes AccessFileApplet.class and ReadFileApplet.class. You can also verify the classes.jar archive file for its contents by executing the following statement. jar -tf classes.jar

When this command is executed, it lists the class files in the JAR file. However, to use the classes.jar file, you need to specify the ARCHIVE property in the APPLET tag of the respective htm file of the specified applet. Look at the following sample APPLET tag: <APPLET CODE=”AccessFileApplet.class” ARCHIVE=”classes.jar” HEIGHT = 300 WIDTH = 600>

Signing JAR Files You need a keystore and a signer’s key pair before signing the JAR files. A keystore is a database of private keys and their associated certificates. It is used for authenticating the corresponding public keys of the private key. The key pair consists of a public key and an associated private key. A key pair can be generated by using the keytool command with the -genkey option. Figure 1-3 depicts the command prompt window with the keytool command executed. Go through the information that is prompted on execution of the command.

FIGURE 1-3 Execution of the keytool command


Chapter 1

Therefore, the public and private key pair is created, which associates the public key with the certificate of the signer. The alias name for the certificate by default is <mykey>. The private key and its associated certificates are stored in a .keystore file located in the user’s home directory. Once the keystore and the certificate are created, the JAR file can be signed by using the private key of the signer. This is done by using the jarsigner command. Consider the following code statement: jarsigner classes.jar mykey

This command, when executed on the command line, asks the user for the keystore and the private key password. The jarsigner utility first opens up the JAR files, and then adds the signature-related information, and finally archives the JAR file again.

Using the Policy Tool You can create or edit a policy file by using the text editor or the Policy tool. However, using the Policy tool reduces typing errors and time. It is also easier as compared to a text editor because you need not know the syntax of policy files. Let’s discuss the various steps involved in creation of user policy files. First, you need to type the command policytool at the command prompt. If the Policy tool cannot locate a policy file, it displays a suitable message and a blank Policy Tool window, as in Figure 1-4.

FIGURE 1-4 The Policy Tool window

21

22

Part I


To add new policy entries, you need to click the Add Policy Entry button in the Policy Tool window. Let’s imagine that you need to grant all the classes in the C:/Trial directory read permission for the file myFile in the C:\Data directory. On clicking the Add Policy Entry button, the Policy Entry window appears as shown in Figure 1-5. In the CodeBase text box, you’ll enter the URL of the classes, that is C:/Trial. The SignedBy text box is used for signing the code. I’ll leave it blank in this example. The next step involves adding permissions to the specified Policy entry. This can be done by clicking the Add Permission button, which opens the Permissions dialog box, as shown in Figure 1-6.

FIGURE 1-5 The Policy Entry window

FIGURE 1-6 The Permissions dialog box


Chapter 1

FIGURE 1-7 The changed Permissions dialog box

From the Permission drop-down list, select FilePermission. In the text box to the right of the Target Name drop-down list, type C:\Data\myFile. Finally, from the Actions drop-down list, select read. The Permission dialog box now looks like Figure 1-7. You’ll click the OK button to add the new permission to the policy entry. The new permission appears in the Policy Entry dialog box, as in Figure 1-8. You can click the Done button, as your task is now accomplished. The Policy Tool window now contains a CodeBase value, as shown in Figure 1-9. You can similarly edit and remove policy entries from the policy files.

FIGURE 1-8 The new permission in the Policy Entry dialog

box

23

24

Part I


FIGURE 1-9 The Policy Tool window with the CodeBase value

Specifying a Keystore by Using the Policy Tool You can also specify keystore entries by using the Policy tool. For example, imagine that you need to grant code from the URL http://java.sun.com/ and signed by the alias name “marc” permission to initiate socket connections to any hosts. To fulfill this requirement, you need to specify the keystore containing the specified alias name and create policy entries for the specified permission. First, let’s specify the keystore containing key information about the alias. To do this, in the Policy Tool window, choose Edit, Change KeyStore. This opens the Keystore dialog box where you specify the URL and the type of the keystore. Assume that the keystore named newKeystore is stored in the Keystore directory in C:. You’ll type this URL in the New KeyStore URL text box. The keystore type can be taken as the proprietary keystore type supported by Sun, which is “JKS”. Therefore, you’ll enter the value, JKS, in the New KeyStore Type text box. The Keystore dialog box now looks similar to Figure 1-10. Now, let’s add a policy entry with a SignedBy alias. You’ll click the Add Policy Entry button in the Policy Tool window. This displays the Policy Entry dialog box. In the CodeBase text box, you’ll enter http://java.sun.com/*. The asterisk (*) signifies all


Chapter 1

FIGURE 1-10 The Keystore dialog box

class and JAR files in the specified directory. In the SignedBy text box, you’ll enter marc. To add the specified permission, click the Add Permission button. The Permissions dialog box appears. From the Permission drop-down list, select SocketPermission. In the text box to the right of the Target Name drop-down list, type *. The * represents all hosts. From the Actions drop-down list, select connect. All these operations help you to specify permissions to make connections to all hosts. The Permissions dialog will look like Figure 1-11. Click the OK button and the new permission appears in the Policy Entry window, as shown in Figure 1-12. Click the Done button in the Policy Entry window. The Policy Tool window appears displaying a line representing the policy entry containing the CodeBase and SignedBy values. Figure 1-13 displays the Policy Tool window as discussed.

FIGURE 1-11 The Permissions dialog box

25

26

Part I


FIGURE 1-12 The Policy Entry window

FIGURE 1-13 The Policy Tool window

You can save this user-defined policy file, by choosing the File, Save As command in the Policy Tool window. This displays the Save As dialog box, which is set to the user’s home directory. You can type the desired file name and click the Save button. Now, let’s discuss application security in Java 2.


Chapter 1

Java 2 Application Security In earlier versions of Java, there were no security restrictions imposed on Java applications because they were treated as the local code. Therefore, the local code had full access to most of the system resources. However, in Java 2, applications are also limited by the permissions specified in the security policy. What was the need to limit applications by these permissions? For example, assume that you have received a Java application either by mail or on a disk. The job of the application is to read a file and print it on the screen page-wise. However, you cannot trust the application completely as you have not gone through the source code. Imagine that when you execute the application, the application reads the file, and then it opens a secret socket connection and transfers data from the file to another system on the network. What do you do? According to you, the application was intended to read the file and print its content on the screen. The malicious application can go to the extent of attacking your computer with viruses or crashing your system. Therefore, in Java 2, local applications are also controlled through policy files and have limited access to system resources When you run an application in Java 2, the security manager is not installed automatically. Therefore, by default, the application has full access to system resources. However, you can invoke the security manager by using the -Djava.security.manager attribute. Once the security manager is invoked, the application will be limited by the same access permissions as for the remote code. Consider the following code: javac ReadWriteFile.java java ReadWriteFile

These statements execute the application without the security manager and, hence, the application has full access to system resources. The following code statement invokes the security manager and restricts the application to accessing limited system resources. java -Djava.security.manager ReadWriteFile

In earlier times, secret information was written in code language and decoded by the person for whom it was intended. This technique was known as cryptography and has been implemented as a security feature in Java. Read on to the subsequent section that contains details of Java 2 and cryptography.

Java 2 and Cryptography The meaning of the word, cryptography, is secret writing or hiding secret data from users and enabling only an authenticated user’s access to this data. The main purpose

27

28

Part I


of cryptography is to protect the confidentiality of data in a Java application. Cryptography refers to the process of converting data or code to cryptographic material. This process takes a stream of input data or code and converts it into encrypted format. The original input data is called clear text, whereas the encrypted form of data is called cipher text. This encrypted data can be either stored on the computer or transmitted over the network without the risk of it being misused. The cryptography feature was introduced in jdk1.1 through the Java Cryptography Architecture ( JCA), which specified the various cryptographic tools available. In Java 2, the JCA comprises of the cryptography core classes and a package called Java Cryptography Extension ( JCE), which supports encryption in Java 2. I will discuss the JCA in the subsequent section.

Cryptographic Architecture The JCA provides a basic framework for providing cryptographic functionality in Java. The cryptographic functionality refers to protecting data using basic cryptographic functions and algorithms. The JCA also includes signature-generation algorithms for signing data and code. APIs for handling keys and certificates are also a part of the JCA. The JCA is also called the provider architecture. Its design enables the separation of the cryptographic design from the implementation. Therefore, vendors have the independence of specifying their customized implementation for the various tools and APIs supported by the JCA. The classes supported by JCA are called engine classes. These classes represent the various cryptographic functions. You may have different implementation designs for these classes. For example, there are various standards for digital signatures. However, there is a single engine class for signatures even if there are variations in the design of digital signatures. Alternatively, there are provider classes, which are offered by different vendors to implement the varied digital signature algorithms. It is possible for a Java application or applet to create its own digital signatures by using the JCA. Therefore, based on the JCA, now a developer can write more complicated programs to exploit the capabilities of applets and remove the remote applet code from the traditional sandbox limitations. However, the user needs to be convinced that the applet belongs to a trustworthy source and is signed by a trusted entity. Therefore, the signer of the code attaches a public key certificate with the code, which enables the user to check the validity of the signature. In jdk1.1, there was no support for keys and access control lists. However, in Java 2, this support has been provided. The JRE comes with a provider named SUN, which provides implementation algorithms for digital signatures and message digests. There are various cryptographic tools available, which will be discussed in the subsequent section.


Chapter 1

Cryptographic Tools There are various tools available to implement cryptography, which mainly focus on encryption. The basic tools fall into the three main categories: ◆ Hashing ◆ Bulk encryption ◆ Public key encryption

The subsequent sections deal with each type of tool in detail.

Hashing Hashing refers to the process of taking an input stream of data and converting it into a fixed-length digest. The digest generated is, in turn, used for data authentication. The digest is a secure method of transmitting data across the network. If a user reads the transmitted data and deciphers it along with the digest, he/she will not be able to modify the original data. Therefore, the data can be authenticated at the receiver’s end because it would contain the same digest as the original data piece.

Bulk Encryption Bulk encryption is also known as secret writing and is used to secure large chunks of data. Data Encryption Algorithm (DEA) and Data Encryption Standard (DES) are common algorithms for encryption. The basic design of these algorithms is that they use a key to jumble or encrypt data, and then, the same key has to be used to decipher or encrypt this data.

Public Key Encryption Public key encryption, instead of using a single key as discussed in bulk encryption, uses a key pair for encrypting and decrypting data. This key pair consists of a public key and a private key. The public key is distributed to available users, whereas the private key is kept secret. The methodology followed in this encryption technique is that if a key is used to encrypt data, the data can be decrypted using the second key in the pair and vice versa. This encryption technique is asymmetric in comparison to the bulk encryption technique that is symmetric. It is called asymmetric because the key used for encryption and decryption is different. When data is to be transmitted across a secure connection, the sender can use the public key to encrypt data for the receiver, who, in turn, can decrypt data with the simultaneous private key. Theoretically, if you have either of the keys, you can decipher the second in the pair because they are bound by a defined mathematical relationship. However, practically,

29

30

Part I


this is impossible because the size of the keys is quite large and it would require a very high effort on the cracker’s part. Therefore, public key encryption is more secure than bulk encryption. However, the public key encryption technique is expensive and, therefore, should not be used when a large amount of data is to be transmitted over a secure connection. Public key encryption can also be used with bulk encryption. In the SSL protocol, the sender and the receiver agree upon a common key while using public key encryption. Therefore, now, only the two parties know about the key and, hence, bulk encryption can be used to transmit data from one end to another. However, the key needs to be decided afresh for every new connection to be started between the sender and the receiver. There are certain limitations or rules for encrypting data. The next section deals with these rules.

Rules for Encryption Java 2 includes engine and provider classes for digital signatures. However, it does not contain classes for bulk or public key encryption. This is due to the limitations imposed by the United States government on cryptographic technology. If these limitations were not imposed, the National Security Agency (NSA) could not decipher messages to check for communication security while transmitting messages across governments and criminal organizations. Therefore, this agency can control the cipher strength of any message. The cipher strength is controlled by the key size used in the encryption algorithm. However, the United States government has relaxed the export rules. Therefore, now, any cipher strength can be exported but it needs to be associated with a key recovery process, which enables the NSA to decipher the key if they suspect a particular piece of code being transmitted. Keeping these rules in mind, JavaSoft created two cryptographic packages for Java. The part of JCA that can be exported is the one that contains tools for signatures, and the part that cannot be exported is the JCE that contains the general encryption rules and regulations. JCE provides support for message authentication codes (MACs), keys, and ciphers.

Summary In this chapter, I discussed the need for security and the role of Java in implementing security in applications and applets. The chapter started with a brief introduction of the Java development and execution environment. I also discussed interfaces and packages in Java 2. Then, I discussed the Java security features and the limitations in Java security. A comparison of Java security across various versions was presented in brief. I discussed Java 2 security features and the security implementation in Java 2 applets and applications. The final section of the chapter focused on the role of cryptography in the Java 2 security implementation. The JCA was discussed along with


Chapter 1

the various cryptographic tools. Finally, the rules specified by the United States government on the usage of encryption were discussed.

Check Your Understanding Multiple Choice Questions 1. Which of the following are Java 2 security tools? a. jar b. jarsigner c. keytool d. Java beans 2. Which of the following is a reusable software component that can be modified by using the Visual builder tools? a. Packages b. Interfaces c. Java beans d. JDBC 3. Which of the following are Java interfaces? a. RMI b. Class loader c. JDBC d. Security manager 4. Which of the following tools do you need to sign applets? a. jar b. jarsigner c. Policy d. keytool 5. Which of the following refers to the process of taking an input stream of data and converting it into a fixed-length digest? a. Public key encryption b. Hashing c. Bulk encryption d. Signing

31

32

Part I


Short Questions 1. How do you specify a security policy for an applet? 2. Explain the process of signing JAR files. 3. How do you implement security in Java 2 applications?

Answers Multiple Choice Answers 1. a, b, and c. The Java security tools are the jar, jarsigner, keytool, and Policy tools. 2. c. Java beans is a reusable software component that can be modified by using the Visual builder tools. 3. a and c. The most used Java interfaces are JDBC, RMI, and Java beans. 4. a and b. First, you need to archive the class files of an applet in a JAR file by using the jar tool. Then, sign the JAR file by using the jarsigner tool. 5. b. Hashing refers to the process of taking an input stream of data and converting it into a fixed-length digest.

Short Answers 1. To specify a security policy for an applet, all you have to do is to edit the appropriate policy configuration file. You can do this in a number of ways, which are listed here: • Set the value of the policy.java property to the name of the appropriate security policy file. • Use the -D command-line option to set the value of the java.policy property to a different security policy file. Consider the following code statement: java -Djava.policy = “try.policy” Trial

This code statement enables you to use the try.policy file while executing the Trial applet class. • Create or edit the default system policy file located at \lib\security\java.policy where is the directory in which the default


Chapter 1

jdk1.2 installation is stored. When you edit the java.policy file, it applies to all the users of the jdk1.2 installation. • You can replace the class, java.security.PolicyFile, used to implement the security policy with another class. You do so by editing the java.security file. All you need to do is change the following code statement policy.provider = java.security.PolicyFile

to policy.provider = Class1

where Class1 is the class name. When the bytecode is interpreted, it first loads the system policy and then acts on the user policy. The security policy file consists of entries called grant entries, which identify the code’s access permissions on various system resources. The permissions are granted based on the code source and the signers of the code. 2. You need a keystore and a signer’s key pair before signing the JAR files. A keystore is a database of private keys and their associated certificates. It is used for authenticating the corresponding public keys of the private key. The key pair consists of a public key and an associated private key. A key pair can be generated by using the keytool command with the -genkey option. Therefore, the public and private key pair is created, which associates the public key with the certificate of the signer. The alias name for the certificate by default is <mykey>. The private key and its associated certificates are stored in a .keystore file located in the user’s home directory. Once the keystore and the certificate are created, the JAR file can be signed by using the private key of the signer. This is done by using the jarsigner command. Consider the following code statement: jarsigner classes.jar mykey

This command, when executed on the command line, asks the user for the keystore and the private key password. The jarsigner utility first opens up the JAR files, and then adds the signature-related information, and finally archives the JAR file again. 3. When you run an application in Java 2, the security manager is not installed automatically. Therefore, by default, the application has full access to system resources. However, you can invoke the security manager by using the -

33

34

Part I


Djava.security.manager attribute. Once the security manager is invoked,

the application will be limited by the same access permissions as for the remote code. Consider the following code: javac ReadWriteFile.java java ReadWriteFile

These statements execute the application without the security manager and, hence, the application has full access to system resources. The following code statement invokes the security manager and restricts the application to accessing limited system resources. java -Djava.security.manager ReadWriteFile

Chapter 2 Java Security Model

I

n Chapter 1, “Security: An Overview”, you learned that Java is a secure language and there are no deviations from this fact as long as the Java system is configured correctly. The built-in security features of Java improve the overall security of your system. This chapter discusses the Java 2 security model, which provides a way to build secure and distributed applications in Java. The chapter begins with a discussion of security history in the various versions of Java and proceeds to discuss the security features of Java 2 in brief.

Java Security Features Java is being widely used in Internet commerce. This requires the usage of Java applets that allow downloading of remote code into a Web browser. Originally, Java was widely used because of its support of applets. Applets enhanced the capabilities of Web browsers so that they could support the execution of downloaded applications. In addition to downloading remote code to the Web browser, the code was automatically updated when you visited the site from which the code was downloaded. This saved the effort of upgrading versions of any application stored locally on your computer each time a new version was introduced. However, this capability was restricted because of network performance and JVM support in Web browsers. The usage of remote code entailed security threats as well. Therefore, security was never sidelined in the case of Java. It became a primary consideration from the very beginning. When you install and execute desktop applications on your computer, many of these applications need access to the local file system. The same could hold true for Java applets that bring remote applications to your computer. Imagine a Java applet from a malicious site attempting to access your local file system. Now did that scare you? Do not panic because from the very beginning Sun has handled this security part quite well. In addition to the risk discussed previously, remote code can also affect system performance by reducing CPU usage or memory utilization. Remote code can also bring in virus attacks. In addition to applets, Java developers create stand-alone enterprise applications as well. Multiple clients on a network access these applications. Therefore, security considerations are not limited to applets as was the case in earlier Java Security models. However, the Java 2 security model offers extensive security features for applications as well.

JAVA SECURITY MODEL

Chapter 2

Let’s now discuss a few basic security features of Java. These are listed here: ◆ The sandbox mechanism permits only local code to access all system

resources. The remote code has access to only limited system resources. I’ll discuss the sandbox security model in detail in the subsequent section. ◆ Language features, such as no pointer arithmetic and array bounds checking,

provide security to the memory resource. ◆ Finally, digital signatures mark a personal ownership by the owner of a spe-

cific code. Therefore, you can check the authenticity of the code owner by verifying whether the code was changed after the owner last signed it. Java Runtime Environment ( JRE) also supports Java security. You have already read about the three basic extensions of the development environment in Java in Chapter 1, “Security: An Overview”. The class loader checks the loading mechanism for Java programs. It prevents the replacement of system components in the runtime environment. The class file verifier verifies the formatting of the remote code by checking the bytecode for typed parameters. It also checks the flow of the internal stacks. Finally, the security manager controls runtime access on the applications for I/O operations, class-loading operations, and thread-manipulation operations. These security mechanisms continue adding new features with each new release of the Java language. The next section discusses the evolution history of the security model according to each version release.

History of Java Security Java is a well-known Internet technology because of its various supporting features, such as it being object oriented, architecturally neutral, portable, and dynamic. Java has become a highly preferable language of the present because of it being architecturally neutral and portable. These features enable a Java program to run on any platform that supports a JVM-enabled browser. This enables the distribution of Java programs across various clients as well as increases the security risk. I will now discuss the security models supported by the JDK 1.0, JDK 1.1, and Java 2 SDK in the subsequent sections.

The Sandbox Security Model The sandbox model is supported by the Java version 1.0 platform. This is a very limited security model where resource access is concerned. Figure 2-1 depicts the sandbox model. This model marks the local code as trustworthy and assigns full access to all valuable system resources, such as files and network connections. On the other

37

38

Part I


FIGURE 2-1 The sandbox security model

hand, remote code has restricted access to these resources, resulting in limiting the vision of dynamic and downloadable applications. Therefore, remote code is marked as untrustworthy. Java applets cannot exploit their functionality because of being limited to a sandbox. They cannot access files, create network connections, or perform write operations. On the other hand, if remote code is removed from the sandbox limitations, there are chances of malicious attacks on the local computer. Therefore, in both the situations, you cannot exploit the Java applet functionality. However, using the trusted code security model in Java 1.1 can solve this problem. The next section discusses this model.

The Trusted Code Security Model The trusted code security model is supported by the Java 1.1 platform. This model overcomes the flaws encountered in the sandbox model. In this model, the limitations on the remote code were reduced without affecting system resources. This model introduced the concept of signed remote code. Remote code with a digital signature that is trusted by the client can have full access to system resources. Therefore, such signed remote code is treated as local code. If the signed code does not belong to a trustworthy source, it is placed in the sandbox where it does not have access to most of the system resources. For example, while downloading the code signed by Sun, you can treat this code as trusted code. Therefore, this code will be assigned all system resources that are assigned to local code on your system. In other words, you can use this code fearlessly like any other product from Sun. If the signed code does not belong to a trustworthy source, it is placed in the sandbox. Figure 2-2 depicts the trusted code security model. Java 1.1 has the jar tool to pack and deliver remote codes along with their digital signatures. The codes are delivered to the destination in the form of JAR files. JAR files

JAVA SECURITY MODEL

Chapter 2

FIGURE 2-2 The trusted code security model

were introduced in Java to reduce the download time of Java applets to the Web browser. This was possible because of the following reasons: ◆ The JAR file can be compared to a ZIP file format where all the compo-

nents of a Java applet are packaged and delivered as one component. This completes the applet download in a single transaction instead of starting a new transaction for every applet component (class files, images, sound files, and so on). Therefore, it saves download time and increases the download speed for the applet download. ◆ Moreover, the JAR file compresses its components and reduces the size of

the files and thereby increases the download speed. For security purposes, the JAR files can be digitally signed, thus authenticating the remote Java applet code. The javakey tool is used to sign the JAR files. You might be wondering whether JAR files can be used across multiple platforms. Yes, the JAR file format is platform-independent. The jdk 1.1 security API consists of the java.security package, which contains the java.security.acl and java.security.interfaces packages. The java security model for jdk 1.1 consisted mainly of cryptographic functions for Java applications. The model in jdk1.1 also contains APIs for message digests, access control lists, digital signatures, and key management. In the jdk 1.1 security model, the access control for remote code was not well defined. If the remote code contained a trustworthy signature, it would have access to system resources. Or else it would be limited to the sandbox. On the other hand, the local code had blind access to all system resources. However, the Java 2 security model with its fine-grained access control meets the gaps of the earlier versions. The next section covers the Java 2 security model in detail.

39

40

Part I


Java 2 Security Model The fine-grained access control in Java 2 provides case-specific security control for remote code. It is not just dependent on the trusted signature attached to the code. Using fine-grained access control, you can provide specific permissions to remote code. For instance, you wish to assign read and write permissions to the file ABC and no permissions to the file XYZ. Depending on the source of the remote code, it is possible to do this through the fine-grained security model. Therefore, developers can specify access permissions depending on their requirements and the source location of the remote code. Now, local and remote code can be confined to resources in a domain according to specific conditions and policies. This is in contrast to the earlier security models where local code was trusted. In the earlier models remote code was not trusted and placed in the sandbox unless it contained a digital signature by an authorized signatory. Moreover, the fine-grained model relieves developers from the overhead of differentiating between local and remote code.

Specifications of Fine-Grained Access Control With the new Java security architecture, you can assign access permissions to system resources, regardless of the fact that the code is local or remote. The permissions are defined depending on what is contained in a policy file. Therefore, the client has rights to decide the permissions to be granted to different sources of code. Now, the users can download applications from the Internet and assign permissions to only specific modules depending on their requirement. At times while downloading code from a site that is considered a trusted source, you are held back by a surprise because the code transmitted a virus to all your e-mail contacts. In the previous versions of Java, you could not control access of the code to system resources in such a way that only specific modules of the code were executed at your computer. However in the case of Java 2, you can specify that the code downloaded from a URL can access only the resources as defined in the policy file. This is possible because the JVM does not assign the restricted system resources to the downloaded code. For example, you can limit the code to have access to only specific files and the code cannot access the remaining files and directories on your local computer. Therefore, with Java 2, you have full access to set permissions for the program actions to be performed on your computer. You can now be very specific about applet actions, defining exactly what an applet is permitted to execute on your computer. Isn’t that great? This type of access control was never possible in the earlier versions of java where the much restricted sandbox security model controlled the JVM resource access. Therefore, applets downloaded in a Java 2-enabled Web browser now have the ability to specify access permissions for susceptible resources on your computer without modifying the browser implementation or the computer platform. This finegrained security model is illustrated in Figure 2-3.

JAVA SECURITY MODEL

Chapter 2

FIGURE 2-3 The fine-grained security model

You might be wondering how this acclaimed fine-grained security model works. What are the security tools and APIs needed to implement this model? The answers to all these queries can be found in the subsequent sections.

Java 2 Security API In addition to the earlier packages contained in the java.security package, certificate interfaces for parsing and managing certificates have been added. This is possible because of two new packages, java.security.cert and java.security.spec, which have been added to the java.security package. The java.security.cert package also provides support to X.509 v3 certificates. The Certificate interface of the java.security package is an interface of abstract methods for managing identity certificates.

NOTE An identity certificate is a guarantee certificate by a principal stating that a public key is that of another principal, where a principal denotes a user, group, or company.

In Java 2, the Certificate interface is deprecated. A new certificate-handling package named java.security.cert is created in Java 2. The java.security.cert package contains the X509Extension interface for X509 extensions. The extensions defined for X509 certificates and crls (Certification Revocation Lists) define methods for relating new attributes with keys and users for managing crl distribution and manage certification hierarchy. The java.security.spec package provides classes and interfaces for key and algorithm parameter specifications. This package contains AlgorithmParameterSpec and

41

42

Part I


KeySpec interfaces that contain specifications for cryptographic parameters and for

key material within a cryptographic key. The next section discusses the Java 2 security tools used for authenticating data and maintaining access control on various system resources.

Java 2 Security Tools Java 2 provides four security tools for implementing security: jar, keytool, jarsigner, and the Policy tool. Each of these tools is discussed in the following list in brief. ◆ The jar tool is similar to the one in jdk 1.1, which is used to pack and

deliver remote codes along with their digital signatures. ◆ The keytool performs a series of tasks. It creates pairs for public and private

keys, manages keystores, and generates signed X509 certificates.

NOTE A keystore is a protected database, and it contains private and public keys and certificates. A keystore is protected through a password, and all the private keys contained in a keystore are in turn protected by different passwords. ◆ The jarsigner tool is used to sign JAR files. It also verifies signed JAR

files. This tool accesses the keystore when it signs or verifies a signature in JAR files. It needs a private key to sign a JAR file and a public key while verifying a signature. Therefore, it accesses the keystore for private and public keys. ◆ The Policy tool is used to define the security policy by creating and updating the policy configuration files. The Policy tool utility is started using the policytool command.

From the preceding sections you know that the Java 2 security model contributes its fine-grained access control to the security policy file, protections domains, and code source. I will discuss these concepts in the next section.

Protection and Permissions You are already aware that permissions to access a particular system object are stored in the security policy file. This file can be edited either manually or by the Policy tool. The domain that contains system objects that can be accessed by a principal is called

JAVA SECURITY MODEL

Chapter 2

the protection domain. Principal is the entity to which permissions are granted, and it can access objects in the protection domain depending on the permissions specified for the particular object in the policy file. In addition to the default policy file, you can also have user-defined policy files. However, at a given point in time, the JVM can assign resources based on permissions specified in a single policy file.

NOTE The Policy class of the java.security package contains the refresh() method, which re-reads the policy files and refreshes the changes in them. You need to explicitly call this method because it cannot be called automatically.

In the Java 2 security model, you can assign permissions to either local or remote code. Both local and remote code are trusted if they come from a reliable source and are signed by a trusted signatory. Both these requirements are met by the code source for the code. The code source is defined by the URL location of the code and a list of trusted signers of the code. The java.security.CodeSource class marks the code source for local or remote code. The constructor function of the CodeSource class takes two parameters—the URL location of the downloaded code as the first parameter and the signers of the code as the second parameter. The first parameter is a URL object whereas the second parameter is a Certificate object.

Description of a Policy File A policy file consists of a group of statements called grant entries. These statements identify the permissions granted to both local and remote code based on the code source. The grant entries identify the code source along with the permissions granted to the code source. The syntax of grant entries states that they begin with the grant keyword followed by the optional SignedBy or CodeBase clause and end with a list of permission entries. The syntax of grant entries is as follows: grant [SignedBy “signer_names”] [, CodeBase “URL”] { permission entries};

The SignedBy clause consists of a list of alias names for all signers of the specific code. This clause is optional if the code has not been signed by any entity. In addition alias names are not case-sensitive. Let’s look at a few examples to understand the concept of the SignedBy clause. SignedBy “Johnson” SignedBy “Johnson, Maria, Sam, Meredith”

43

44

Part I


The CodeBase clause identifies the URL location of the downloaded code. The example that follows specifies that the code is downloaded from the JohnsieToys Web site. CodeBase “http://www.johnsietoys.com”

You’ll learn more about grant entries in detail in the subsequent sections.

Protection Domains After reading about the code source and policy files, let’s try defining the protection domain according to these concepts. The scope of a protection domain is applicable to the code source and permissions specified in the policy files. Therefore, when a class is loaded, it is mapped to a protection domain depending on its code source. The access permissions of the code are described through the grant entries in the policy file. You might be wondering whether classes having similar permissions are placed in similar protection domains. This again depends on the code’s code source. If the classes have a same set of permissions but belong to different code sources, they are placed in different protection domains. Protection domains are of two types, application and system domains. An application domain constitutes the applets or applications that are given access permissions as defined by the security policy file. On the other hand, the system domain contains all the system code, which is granted all permissions. Therefore a policy file does not control entities of a system domain. After being clear about the basic security mechanisms, let’s see the changes in classes in Java 2 over the previous versions.

Classes in Java 2 In the earlier versions of Java, such as jdk 1.1, the class path default value included the path specifying the directory containing system classes. The system classes were contained in a ZIP file. The class path also included the path of the current working directory. You already know that you can create your own class files as well. These are stored in the classes folder. To add new libraries to the default class path, you can use the java tool, the CLASSPATH environment variables, and the –classpath and –cp flags. If you use the –classpath and –cp flags, the class path contains both the original classes.zip reference and the new classes that you created. This will become clearer in the following code statement: java -classpath C:\jdk1.1.7\lib\classes.zip; \app\classes

JAVA SECURITY MODEL

Chapter 2

On the other hand, if the CLASSPATH environment variable is set, the class path contains the classes.zip file and the current working directory is replaced by the recently assigned values. Therefore, you need to explicitly specify the current working directory while setting the CLASSPATH environment variable. This resulted in discrepancy while setting the class path through either of the two ways discussed previously. This resulted in different versions of classes.zip file being generated. This problem was solved in Java 2 where the -classpath flag and the CLASSPATH environment variable now performed the same task. The only difference from the earlier versions was that now the class path was further split into three separate paths. These paths are explained in the subsequent sections.

The Extensions Mechanism The extensions mechanism is a new feature of Java 2. Extensions are groups of packages and classes used to extend the functionality of the Java platform. This is done by the extension mechanism where the runtime environment finds and loads extension classes without naming them in the class path. Extension classes are used in a similar manner as you use system classes. They are called so because they extend the core API of Java 2. There have been additions to the core API since the various version releases in Java. Therefore, the extensions mechanism extends the functionality of the Java platform without increasing the size of the core API. In Java 2, the process of adding new libraries is now considerably simple. You can skip the usage of the CLASSPATH environment variable or the - classpath command now. When you place the JAR file containing the extensions in the extensions directory, it is added. Such an extension is called an installed extension. On the other hand, a download extension is one in which you refer to a JAR file from another JAR file. Installed extensions are JAR files in the lib/ext directory. However the location of installed extensions can be changed during compile time by using the -extdirs flag followed by the directories separated by semicolons. On the other hand, download extensions include classes and JAR files, which are specified in the Class-Path headers in manifests of other JAR files. Consider the code statement that follows by assuming that new.jar and new1.jar are two files stored in the same directory and the manifest of new.jar contains the following header. Class-Path: new1.jar

Now, the classes in new.jar can invoke the classes in new1.jar without including new1.jar classes in the class path. Classes for downloaded extensions are specific to the application or the applet that uses them. On the other hand, the classes in installed extensions can be used by any code.

45

46

Part I


Application Class Path The class path for an application is set by the java.class.path property. The value contained in this property is called the application class path. The application class path is used to specify the application URL search path for loading the classes and resources of the specified application. It is used to find the location of user-defined classes that are not part of extensions or the system classes. The default value of the java.class.path property is marked by the CLASSPATH environment variable or is set to the current directory if the earlier (CLASSPATH) is missing. The class path can be set using the - classpath option or the CLASSPATH environment variable. The - classpath option is much preferred because it can be used to set the class path individually for different applications. In Java 2, classes are located by searching for bootstrap classes, extension classes, and class path in the same order as specified.

System Class Path In the earlier versions of Java, the system classes were stored in ZIP files. However, in Java 2, they are stored in JAR files where rt.jar contains the runtime classes and the tools.jar file contains the tool classes supported by SDK. All these files now are a part of the default installation of Java 2. You no longer need to use the CLASSPATH environment variable or the -classpath command to specify the system classes. Now, the location of the system classes is set automatically during runtime by the sun.boot.class.path variable. In default installation, the boot class path contains the rt.jar file containing the default system class files. The default boot class path can be changed to include another JAR file containing a different version of the system class files by using the bootclasspath compile time flag and the -Xbootclasspath runtime flag. Your understanding will be clearer once you look at the following example: javac -bootclasspath E:\newfiles\new.jar First.java java -Xbootclasspath: E:\newfiles\new.jar First

The first statement sets the boot class path to the new.jar file, thus overriding the default settings. The -bootclasspath flag is used at by compile time whereas the Xbootclasspath variable is used at runtime to set the path to use the new.jar file containing the new system classes. To execute the Java program, it is essential that both the rt.jar file and the application class file be specified for the JVM at runtime. Therefore, you need to explicitly set the boot class path to the rt.jar file containing the default system classes. Consider the following example: java -Xbootclasspath: E:\newfiles First

JAVA SECURITY MODEL

Chapter 2

This statement gives an error because the JVM cannot locate the rt.jar file containing the system classes. It could locate First.java because it was saved in the newfiles directory. The following command executes correctly as it specifies both the rt.jar file and the location of the application class file. java -Xbootclasspath: E:\jdk1.2\jre\lib\rt.jar; E:\newfiles First

In the Java 2 platform, the classes that are trusted are those that are specified in the boot class path. Therefore, you need to explicitly specify the path of the rt.jar file for error-free execution at runtime. After being acquainted with the changes in the class path in Java 2, let’s discuss the Java 2 class loading mechanism, which plays a critical role in imparting security to Java applications and applets.

Java 2 Class Loader As the name suggests, the main task of the class loader is to locate and fetch classes. However, the class loader refers to the policy file and accordingly defines the permissions for the specified class while fulfilling its primary task. In the earlier versions of Java, all local code and trusted remote code were given full access to all system resources. On the other hand, the code that was not trusted was given access to limited system resources. The security manager looks after resource access, and the class loader fetches the classes based on the security permissions specified. Therefore, each application had customized SecurityManager and ClassLoader classes. However, Java 2 has improved these classes. The SecurityManager class can be instantiated, which is in contrast to the earlier versions where it was an abstract class. A new class named SecureClassLoader is created in Java 2, which extends the ClassLoader class. This new class provides an additional support while defining classes with associated code source and permissions as specified in the system policy file.

Working of the SecureClassLoader Class After executing a Java application or applet, an object of the SecureClassLoader class is created. This object locates and loads the class file of the specified Java program. Then, a subclass of the SecurityManager class is created at runtime. Finally, the main() or init() method is called. Therefore, the main task for implementing security in this process is imparted to the SecureClassLoader class, which ensures the safe loading of classes at runtime. The SecureClassLoader class locates classes for the JVM by following the class search path. It begins by looking for class files in the boot class

47

48

Part I


path followed by the installed extensions. Finally, the classes specified by the application class path are checked. After the class is located and loaded in the JVM, the SecureClassLoader class specifies a protection domain for the class. Firstly, a code source is created for the specified class by referring to the code base and the signatures attached to the code. Then, the code source fetches the protection domain of the class, which contains the specified permissions for access control of resources at runtime. Therefore, the SecureClassLoader class repeats this process until all classes required to run the program are loaded in the JVM along with their protection domains.

Resource Access Control While executing a Java program, you might need access to various protected resources, such as the file system or network of the local computer or access to files for I/O or other resources defined in the program. It is the SecurityManager class that looks after resource access for running a Java program. The security manager determines whether requests for resources are to be met or not from a security perspective. The security manager’s checkPermission method determines whether a runtime resource access request should be granted or denied. This method takes as an argument a Permission object. If the resource request is permitted, the checkPermission() does not return anything. Or else, a SecurityException is thrown. The checkPermission method with a single permission argument performs security checks within the context of the currently executing thread. Therefore, the checkPermission method verifies that the protection domain of all classes in the current thread include permissions to perform the requested operation. These permissions are specified in policy files. The next section covers the policy files in detail.

Policy Files The policy file containing the access permissions for code from various sources is stored in the lib\security directory. You can also use multiple policy files to specify the overall system policy. However, the default setting includes a single system-wide policy file and a user-defined policy file in the user’s home directory. A policy file contains a list of grant directives. It may also contain a keystore entry along with the grant entries. This is necessary when a grant entry contains a certificate by a signer and these certificates are stored in the keystore.

Grant Directives There are several Permission classes in Java 2. All of these classes are derived from the java.security.Permission class, which is an abstract class. Further classes are derived

JAVA SECURITY MODEL

Chapter 2

from it to represent various accesses, such as I/O or network access. Objects of these permission classes are created by passing two arguments, the resource to be accessed (file name/socket number) and the action to be performed on the resource (open, listen, read, or write). If the target Permission class has no applicable action with it, the second parameter is null in this case. Examples of Permission classes that have actions associated with them are FilePermission and SocketPermission. In addition to the various permission classes in Java 2, there is a special permission class named AllPermission. This class provides access to all system resources. This class should be used intelligently to impart security. It can be used by system administrators who need access to all system resources under a specific set of permissions. This class indicates that you have the required permissions to perform all actions on specified resources. You’ve already read that a policy file contains permissions specified by grant entries, which in turn contains a code source and a list of permissions. Let’s discuss each part of the grant entry in detail.

Code Source The code source consists of two parts, the code base and the digital certificates used to sign the class code. ◆ The code base specifies the URL or location from where the code is down-

loaded. The code base field of a grant entry is optional. When it is omitted, permissions can be granted to code from various sources. The following code statement specifies the code URL marked by the CodeBase keyword. CodeBase “http://www.mybooks.com”

◆ The digital signatures for the code are specified by the SignedBy keyword.

This field of a grant entry is again optional. When it is omitted, permissions can be granted to both signed and unsigned code. Consider the following code statements: SignedBy “Johnson” SignedBy “Johnson, Maria, Sam, Meredith”

The code must be signed by all the signers specified in the SignedBy clause list to be granted permissions. This statement stands true for multiple signers as well.

Permission List The permission list may contain many permission entries. The beginning of the entries in the permission list is marked by the permission keyword. Next, all these entries contain the following parts in common.

49

50

Part I


◆ The permission entries must contain the full name of the specified Permission class along with the package. For example, the entry java.io.FilePermission states that the FilePermission class lies in the java.io package. ◆ Next, there is a quoted string value specifying the target for the Permission

class. For example, “E:\\Temp\\MyFile.txt”

This quoted string acts as a target for the FilePermission class where you need permissions for accessing MyFile.txt. However, this field can be omitted for the AllPermission class. ◆ There is another quoted string specifying the actions permitted on the target. For example, the quoted string “read, write, execute” can be actions that you need to perform on the MyFile.txt. All permission classes need

not have actions associated with them. Exceptions to this statement are FilePermission, PropertyPermission, and SocketPermission. ◆ Finally, you need to specify the digital certificates used by the permission classes. These are specified by the SignedBy keyword. This field is optional.

The syntax discussed previously should be followed failing which might result in errors during compile time by the JVM. A single mistake in the policy file might put the security of the entire system at stake. However, the Policy tool prevents errors in manual editing of the default policy file. The following section discusses the default system policy file.

Default System Policy File The default system policy file is stored in the lib/security directory under the java home directory. The default policy file contains the following code: // Standard extensions get all permissions by default grant codeBase “file:${java.home}/lib/ext/*” { permission java.security.AllPermission; };

// default permissions granted to all domains

grant { // Allows any thread to stop itself using the java.lang.Thread.stop()

JAVA SECURITY MODEL

Chapter 2

// method that takes no argument. // Note that this permission is granted by default only to remain // backwards compatible. // It is strongly recommended that you either remove this permission // from this policy file or further restrict it to code sources // that you specify, because Thread.stop() is potentially unsafe. // See “http://java.sun.com/notes” for more information. permission java.lang.RuntimePermission “stopThread”;

// Allows anyone to listen on un-privileged ports permission java.net.SocketPermission “localhost:1024-”, “listen”;

// “Standard” properties that can be read by anyone

permission java.util.PropertyPermission “java.version”, “read”; permission java.util.PropertyPermission “java.vendor”, “read”; permission java.util.PropertyPermission “java.vendor.url”, “read”; permission java.util.PropertyPermission “java.class.version”, “read”; permission java.util.PropertyPermission “os.name”, “read”; permission java.util.PropertyPermission “os.version”, “read”; permission java.util.PropertyPermission “os.arch”, “read”; permission java.util.PropertyPermission “file.separator”, “read”; permission java.util.PropertyPermission “path.separator”, “read”; permission java.util.PropertyPermission “line.separator”, “read”; permission java.util.PropertyPermission “java.specification.version”, “read”; permission java.util.PropertyPermission “java.specification.vendor”, “read”; permission java.util.PropertyPermission “java.specification.name”, “read”; permission java.util.PropertyPermission “java.vm.specification.version”, “read”; permission java.util.PropertyPermission “java.vm.specification.vendor”, “read”; permission java.util.PropertyPermission “java.vm.specification.name”, “read”; permission java.util.PropertyPermission “java.vm.version”, “read”;

51

52

Part I


permission java.util.PropertyPermission “java.vm.vendor”, “read”; permission java.util.PropertyPermission “java.vm.name”, “read”; };

The first grant entry specifies the code base URL whereas there are no signers for the code specified. The AllPermission class grants all permissions to JAR files from the Java extensions directory. The second grant entry also does not specify any signers. This grant entry lists the permissions to be granted to the system classes. The next section covers the security management features in Java 2.

Managing Security in Java 2 The security manager is used to manage security in Java 2. Managing security applies both to applications and applets. The main task of the security manager is to perform access control checks depending on the current security policy. When an applet is running, the AppletViewer and the current browsers install the security manager automatically. However, the security manager is not installed automatically in the case of running applications. While running the application, the java command line option -Djava.security.manager is provided. Consider the following code statement: java -Djava.security.manager MyFile

Therefore, you are applying the security policy to the MyFile application explicitly through this command statement. In the earlier versions of Java, applications were not run under security policies because all local code was trusted and assigned all system resources. Therefore, the -Djava.security.manager is a new flag in Java 2. You can also specify customized security managers for your Java applications. The following code statement shows the implementation of the previous concept. java -Djava.security.manager=NewSecurityManager MyFile

NOTE The Java applications can also call the setSecurityManager method of the java.lang.System class.

The security manager can refer to both the system-wide policy file or customized userdefined policy files for implementing security. I have already discussed the system-wide policy file, so let’s discuss the user-defined security policy in the next section.

JAVA SECURITY MODEL

Chapter 2

User-Defined Security Policy In addition to the default system policy file, you can create user-defined security policy files. To do this, you can use the -Djava.security.policy command. Consider the following code statements: java -Djava.security.manager -Djava.security.policy=NewPolicy MyFile java -Djava.security.manager -Djava.security.policy==NewPolicy MyFile

The first statement specifies that the NewPolicy file will be used in addition to the remaining security policy files for implementing application security, whereas the second statement specifies that only the NewPolicy file will be used for implementing application security and that all other files will be overridden.

Summary This chapter discussed the Java security model. First, I talked about the Java security features followed by a history of Java security models across various versions. The sandbox, the trusted code, and the Java 2 fine-grained security models were discussed in detail. Next, the Java 2 security tools and API were discussed. The class path in Java 2 is split into three separate paths, the system class path, application class path, and the extensions framework. All these were discussed in detail in the chapter. Then, the functionality of Java 2 class loader was discussed. Finally, I discussed the policy files and the security manager.

Check Your Understanding Multiple Choice Questions 1. The concept of signed remote code was introduced in which security model? a. The sandbox security model b. The trusted code security model c. The fine-grained security model d. The jdk1.1 security model 2. Which of the following statements is true? a. The permissions to access a particular system object are stored in the security policy file. b. You can have user-defined policy files.

53

54

Part I


c. JVM refers to multiple policy files while assigning permissions. d. The protection domain of a principal contains the system objects that are accessible by the specified principal. 3. Which of the following clauses are optional in a grant entry? a. SignedBy b. grant c. CodeBase d. Permission entries 4. Which of the following tools is used to add new libraries to the default class path? a. The CLASSPATH variable b. The –classpath flag c. The –cp flag d. keytool 5. What does the following code statement signify? java -Djava.security.manager -Djava.security.policy==NewPolicy MyFile

a. The NewPolicy file will be used in addition to the remaining security policy files for implementing application security. b. Only the NewPolicy file will be used for implementing application security and all other files will be overridden. c. No policy file is used for implementing application security. d. Only the security manager is used to implement application security.

Short Questions 1. Explain the extension mechanism in Java 2. 2. Explain the use of code source in grant entries. 3. Explain the working of the SecureClassLoader class.

Answers Multiple Choice Answers 1. b. The trusted code security model introduced the concept of signed remote code.

JAVA SECURITY MODEL

Chapter 2

2. a, b, and d. The permissions to access a particular system object are stored in the security policy file. This file can be edited either manually or by the Policy tool. The domain that contains system objects that can be accessed by a principal is called the protection domain. Principal is the entity to which permissions are granted, and it can access objects in the protection domain depending on the permissions specified for the particular object in the policy file. In addition to the default policy file, you can also have userdefined policy files. However, at a given point in time, the JVM can assign resources based on permissions specified in a single policy file. 3. a and c. The syntax of grant entries states that they begin with the grant keyword followed by the optional SignedBy or CodeBase clause and that they end with a list of permission entries. 4. a, b, and c. To add new libraries to the default class path, you can use the java tool, the CLASSPATH environment variables, and the –classpath and –cp flags. 5. b. Only the NewPolicy file will be used for implementing application security; all other files will be overridden.

Short Answers 1. The extensions mechanism is a new feature of Java 2. Extensions are groups of packages and classes used to extend the functionality of the Java platform. This is done by the extension mechanism where the runtime environment finds and loads extension classes without naming them in the class path. Extension classes are used in a similar manner as you use system classes. They are called so because they extend the core API of Java 2. There have been additions to the core API since the various version releases in Java. Therefore, the extensions mechanism extends the functionality of the Java platform without increasing the size of the core API. In Java 2, the process of adding new libraries is now considerably simple. You can skip the CLASSPATH environment variable or the -classpath command now. When you place the JAR file containing the extensions in the extensions directory, it is added. Such an extension is called an installed extension. On the other hand, a download extension is one in which you refer to a JAR file from another JAR file. Installed extensions are JAR files in the lib/ext directory. However the location of installed extensions can be changed during compile time by using the -extdirs flag followed by the directories separated by semicolons. Download extensions include classes and JAR files, which are specified in the Class-Path headers in manifests of other JAR files.

55

56

Part I


2. The code source consists of two parts, the code base and the digital certificates used to sign the class code. The code base specifies the URL or location from where the code is downloaded. The code base field of a grant entry is optional. When it is omitted, permissions can be granted to code from various sources. The following code statement specifies the code URL marked by the CodeBase keyword. CodeBase “http://www.mybooks.com”

The digital signatures for the code are specified by the SignedBy keyword. This field of a grant entry is again optional. When it is omitted, permissions can be granted to both signed and unsigned code. Consider the following code statements: SignedBy “Johnson” SignedBy “Johnson, Maria, Sam, Meredith”

The code must be signed by all the signers specified in the SignedBy clause list to be granted permissions. This statement stands true for multiple signers as well. 3. After executing a Java application or applet, an object of the SecureClassLoader class is created. This object locates and loads the class file of the specified Java program. Then, a subclass of the SecurityManager class is created at runtime. Finally, the main() or init() method is called. Therefore, the main task for implementing security in this process is imparted to the SecureClassLoader class, which ensures the safe loading of classes at runtime. The SecureClassLoader class locates classes for the JVM by following the class search path. It begins by looking for class files in the boot class path followed by the installed extensions. Finally, the classes specified by the application class path are checked. After the class is located and loaded in the JVM, the SecureClassLoader class specifies a protection domain for the class. First, a code source is created for the specified class by referring to the code base and the signatures attached to the code. Then, the code source fetches the protection domain of the class, which contains the specified permissions for access control of resources at runtime. Therefore, the SecureClassLoader class repeats this process until all classes required to run the program are loaded in the JVM along with their protection domains.

Chapter 3 The Java Virtual Machine

I

n Chapter 1, “Security: An Overview”, I discussed the development and execution environment in Java. You are aware that the execution environment consists of Java Virtual Machine ( JVM), which is chiefly responsible for the secure execution of Java programs. In this chapter, I’ll discuss the various components of JVM and their role in implementing security in Java programs.

JVM Safety Features JVM has several built-in security features that improve the robustness of Java programs. Most of these safety features are linked to the bytecode operating in JVM. A few of these safety features are structured memory access, which is devoid of any pointer arithmetic, array bounds checking, automatic garbage collection, and checking for null references. Due to these safety features, the programs that execute on JVM cannot exploit the memory as the memory can be accessed only in structured ways. In addition to memory checks, JVM checks how you refer to an object, access an array, or try to use a null reference. For any invalid task performed by you, JVM either raises a meaningful exception or terminates the running program. Therefore, the previous safety features not only make Java programs robust, they also help in making the execution of Java programs more secure. Unrestrained memory access is a major security risk. For example, if a hacker identifies the location of a class loader in memory, the hacker can reference the class loader by using pointers and manipulating the information stored in it. Because pointer arithmetic is not permissible in Java, the cracker’s harmful intentions of accessing JVM internal memory are restrained. Another feature that provides safety for memory access is that the memory layouts are not specified in the class files or JVM specification. Memory layouts refer to the data areas created at runtime in JVM. These data areas are memory locations that store the data needed by JVM for the execution of a Java program. For example, a method area is used to store bytecodes, and JVM heap is used to store the objects created by a running program. You will read more about these method areas in subsequent sections. Therefore, a class file does not contain any information regarding memory addresses. All this information is decided by JVM at runtime. For example, while executing a program, JVM decides where to store the loaded class files and the data contained within them in its internal memory. When the objects are created, JVM determines the memory address to be allocated to these objects. Therefore, a cracker cannot know

THE JAVA VIRTUAL MACHINE

Chapter 3

the memory addresses of the data contained in a class file by looking at it. The JVM specification also does not give them any clues regarding this information because the memory layout is not included in it. It is the task of JVM designers to decide the data structure and the memory location to represent the data areas in their JVM implementation. Another safety feature that contributes to the security of JVM is error handling through exceptions. Therefore, a JVM does not crash if it encounters a security violation; instead, it raises an exception that stops the execution of the thread in which the error was thrown. Let’s see how these safety features are built into the JVM architecture. The next section discusses this.

The JVM Architecture The behavior of a JVM implementation is defined in terms of subsystems, data types, and instructions. These components form the architecture of JVM. Every implementation of Java has a class loader subsystem and an execution engine. The class loader subsystem is responsible for loading classes and interfaces in JVM. The execution engine is responsible for executing the methods of the loaded classes. JVM needs memory to store objects, parameters to methods, return values, or the result of any computation. It organizes this memory in data areas such as heaps, method areas, and native method stacks. JVM components that implement security in the execution environment are the class loader, class file verifier, and security manager. The internal architecture of JVM is depicted in Figure 3-1. I’ll discuss the JVM components in detail in the subsequent sections.

The Class Loader When a program is executed, the data or files needed by the program are provided by the operating system. The operating system has access to the file system where it searches for class libraries. It also has access to all the I/O functions in the program being executed. However, in case of Java programs, this task is performed by the class loader. Prior to the execution of a Java program, JVM needs to fetch the respective classes associated with the program and load them in memory. The operating system is not involved in class fetching and loading because the classes are not loaded from the same location and therefore, an integrity check for classes cannot be defined. Classes are mainly of two types: trusted and untrusted. The JRE classes found in the

59

60

Part I


FIGURE 3-1 The internal architecture of JVM

boot class path are designated as trusted. The overhead of verification is removed for these classes and they can be directly executed unlike untrusted classes. In earlier versions of Java, all the local files were treated as trusted. However, in Java 2, all local classes that are not specified in the boot class path are treated as untrusted. The classes loaded from a network or a Web server are also treated as untrusted. The class verifier verifies all the untrusted classes, and these classes are assigned permissions as specified in the security policy of the security manager. Therefore, due to the different class sources, the mechanism for loading them is also different. JVM may support more than one class loaders, which are supported by the class loader subsystem. A Java application can support two types of class loaders, the primordial class loader and the class loader objects. There is a single primordial class loader, which is a part of JVM implementation. The primordial class loader loads only the trusted classes and Java API classes. On the other hand, the class loader objects are programmed to load classes in customized ways. For example, they may be used to load classes from the network or a remote Web server. Therefore, JVM trusts the classes loaded by the primordial class loader and does not trust those loaded by the class loader objects. Thus, the classes loaded by the primordial class loader need not be verified by


Chapter 3

FIGURE 3-2 The class loader architecture

the class file verifier and may be directly passed to the execution engine. However, this does not hold true for the classes loaded by the class loader objects, which need to be verified by the class file verifier. Figure 3-2 depicts this class loader architecture.

The Class File Verifier The class file verifier checks that the loaded class files have a proper internal structure. If the specified class file is not up to the mark, the class file verifier raises an exception. Class files can also be generated without the Java compiler. Therefore, class files can be created by hackers to solve their malicious purposes. Because class files store just binary information, it is difficult for the class file verifier to distinguish between the class files generated by the compiler and those generated by other means. A class file verifier helps in implementing security by achieving program robustness. For example, imagine that a cracker places a class file containing a method that loops beyond the limits specified for an array. Such a method could either cause JVM to crash or temporarily suspend its operation. It is the task of the class file verifier to check for class file integrity and avoid such incidents. The verifier checks the size, structure, and features of a class file. It is up to the JVM designers to decide when

61

62

Part I


JVM will perform these checks. However, most of them design JVM such that these checks are performed just after the classes are loaded in JVM. You’ll read more about how the class file verifier actually achieves program robustness in Chapter 5, “The Class Loader and the Class File Verifier”.

The JVM Heap The heap stores all the objects being created by a running Java program. Objects are created dynamically by using the new operator. The memory for these objects is allocated in the heap at runtime. Garbage collection refers to the process of releasing the memory held by these objects once they are destroyed or are no longer needed in the program. This implies that the memory held by an object that is no longer needed in the program is recycled. Instead, this heap space can be used by another object. The garbage collector is also involved in heap fragmentation. When a program is still executing, the objects that are being cleared by the garbage collector leave free blocks of heap memory between the memory spaces already occupied by active objects. Assume that an object that needs to be allocated requires less memory space than the total free memory in the heap. However, this memory space is not present in continuous memory locations, indicating a need to increase the memory size of the heap. This can affect the performance of a currently running program. Java does not contain a default implementation for a garbage-collector heap. The JVM specification only includes the need for a heap and a garbage collector. However, JVM does not specify the working of the heap or the garbage collector. Therefore, it is up to the JVM designer to decide on the implementation of the heap and the garbage collector. This acts as a good security measure because a hacker has no idea about how JVM stores objects in the heap. This renders it difficult to attack JVM through memory definitions.

The Method Area When you define a new class or an interface in your Java program, you actually provide a new type for the program. This new type can be used as other data types for creating instances in the Java program. When types are loaded by JVM, all the typespecific information such as the class attributes and the class methods are stored in a memory area called the method area. The class information stored in the method area is similar to the information stored in the class file. The only difference is that the organization of information in the method area is not as per Java specifications. Therefore, JVM designers actually decide how to store information in the method area. The designers should keep in mind two options while designing the method area implementation, namely, the execution speed of the application and the memory con-


Chapter 3

straints. Therefore, designers should choose such data structures that facilitate speedy execution of Java programs. However, they might have to trade off the memory aspect in this case because redundant information is stored in the method area to increase execution speed. It is up to the designer to decide the data structures, which enhance the performance of their implementation. The size of the method area is not fixed and can be increased or decreased according to the application requirement. The method area need not assign contiguous locations of memory; the memory can be assigned in a heap. Therefore, the concept of garbage collection also applies to the method area.

The Native Method Stacks In the preceding sections, you have already read that data areas are defined by JVM at runtime. However, a currently executing Java application may also need data areas for the native methods. There are very few security restrictions for native methods. Thus their capabilities are not limited. Native methods can use runtime data areas such as registers, stacks, or heaps for memory allocation. They are implementation-dependent, and the designers can decide how a native method will be invoked in a running Java application. When a running program invokes a native method, JVM directly links to the method instead of pushing the necessary information on to the stack. A native method interface uses a native method stack for locating and loading native methods in JVM. For example, assume that the native method interface uses the C language. Then, the native method stacks would be C stacks. The native method stacks in this implementation can contain function parameters and return values. Therefore, the implementation of the native method interface and the native method stack is entirely designer-dependent.

Just-in-Time (JIT) Compilers You are already familiar with the fact that the bytecodes generated after compilation are interpreted at runtime in the execution engine. This involves the conversion of each bytecode instruction to its native counterpart. This increases the execution time for Java programs, thereby affecting their performance. Therefore, to improve the performance of Java programs, the number of times the bytecode instruction is converted to machine code by JVM interpreter needs to be reduced. Note that the security aspect of the Java programs is attributed to the bytecode and the class file format. These collectively allow you to run your Java programs on any JVM and also test the code for safety. The bytecode should be translated to native machine code only after the class files are loaded and verified. Either the class files, as a whole, can be translated into machine code after being loaded and verified, or only the methods required

63

64

Part I


currently can be converted to machine code. If class file, as a whole, were translated to machine code, it would reduce the performance of the Java program. This is so because some methods in the class file may not be executed and the time taken for their conversion to native machine code would be wasted. Therefore, the second option of translating only the methods that need to be executed sounds better as it would improve the program performance. This process of translating bytecode to machine code as and when required is called JIT compilation. JIT compilers are very effective because they compile only the code that is actually executed. Therefore, the methods that are executed frequently can be retrieved from the native method area and executed on the fly. This process occurs during runtime.

The JVM Execution Engine The core component of a JVM implementation is the execution engine, which is responsible for the invocation and execution of methods. In JVM specification, the functionality of the execution engine is defined in terms of the instructions it executes. Once the specified class files have been loaded, the execution engine invokes the main function of the initial class in the program. After this, the execution of the program depends on the type of instruction loaded currently. The different types of instructions are for: ◆ Object creation ◆ Arithmetic calculation ◆ Array manipulation ◆ Type conversion ◆ Control flow modification

Therefore, through these types of instructions, the execution engine looks after memory management and thread management, and also invokes native methods.

The Security Manager When code is loaded from different sources, it is checked for integrity by the class file verifier. This check is, however, performed for the internal class loaders within JVM. For external checks from JVM, you can use the security manager. For example, you can use the security manager to prevent applets from accessing your file system or prevent applications from starting unsafe network connections. Security managers can be customized; therefore, you can create custom policy files for your Java applications. The permissions for the unsafe tasks performed in an application are defined in this custom security policy. For each such action, there is a corresponding method defined


Chapter 3

in the security manager, which checks whether the specified action is permissible. Each such method begins with the check keyword. For example, a checkWrite() method checks whether a specified application thread is allowed to write in a given file on the system. The following actions are regulated by the check methods in the security manager. ◆ Writing to a file ◆ Reading from a file ◆ Deleting a file ◆ Opening a connection with a specified host ◆ Accepting a connection from a specified host ◆ Causing a specified application to exit

There are many more actions in addition to those listed here that are regulated through check methods in the security manager. You’ll read more about security managers in Chapter 6, “Java 2 Security Manager”.

Summary In this chapter, I discussed the security and safety features of JVM. I also discussed the components and the architecture of JVM that contribute to security. The JVM components were then discussed in detail. I discussed the use of JIT compilers for improving the performance of Java programs. The class loader, class file verifier, and security manager are the core components of JVM that contribute to the security of the system. I discussed these components and the runtime data areas namely, the JVM heap, the method areas, and the native method stacks.

Check Your Understanding Multiple Choice Questions 1. Which of the following are JVM safety features? a. Structured memory access b. Automatic garbage collection c. Pointer arithmetic d. Array bounds checking

65

66

Part I


2. Which of the following statements is true? a. JVM decides where to store the loaded class files. b. JVM determines the memory address to be allocated to new objects. c. Memory layout information is included in the class files. d. JVM designers decide the data structure and the memory location to represent the data areas in their JVM implementation. 3. Which of the following are JVM components? a. Class loader b. Class file verifier c. Native method stacks d. keytool 4. Which of the following statements is true for class loaders? a. JVM can support multiple class loaders. b. JVM supports multiple primordial class loaders. c. JVM trusts the classes loaded by the primordial class loader. d. Classes loaded by class loader objects are not verified by the class file verifier. 5. Which of the following tasks is performed by the class file verifier? a. The class file verifier checks that the loaded class files have a proper internal structure. b. The class file verifier creates class files. c. The class file verifier checks for class file integrity. d. The class file verifier checks the size, structure, and features of a class file.

Short Questions 1. Explain just-in-time compilation. 2. What is the need for native method stacks? 3. Explain garbage collection and its need.

Answers Multiple Choice Answers 1. a,b, and d. The JVM safety features are structured memory access, which is devoid of any pointer arithmetic, array bounds checking, automatic garbage collection, and checking for null references.


Chapter 3

2. a, b, and d. When the objects are created, JVM determines the memory address to be allocated to these objects. Therefore, a cracker cannot know the memory addresses of the data contained in a class file by looking at it. The JVM specification also does not give them any clues regarding this information because the memory layout is not included in it. 3. a,b, and c. JVM organizes memory in data areas such as heaps, method areas, and native method stacks. JVM components that implement security in the execution environment are the class loader, class file verifier, and security manager. 4. a and c. JVM may support more than one class loader, which are supported by the class loader subsystem. There is a single primordial class loader, which is a part of JVM implementation. The primordial class loader loads only the trusted classes and Java API classes. On the other hand, the class loader objects are programmed to load classes in customized ways. Therefore, JVM trusts the classes loaded by the primordial class loader and does not trust those loaded by the class loader objects. Thus, the classes loaded by the primordial class loader need not be verified by the class file verifier and may be directly passed to the execution engine. However, this does not hold true for the classes loaded by the class loader objects, which need to be verified by the class file verifier. 5. a, c, and d. The class file verifier checks that the loaded class files have a proper internal structure. It is the task of the class file verifier to check for class file integrity. The verifier checks the size, structure, and features of a class file.

Short Answers 1. The bytecodes generated after compilation are interpreted at runtime in the execution engine. This involves the conversion of each bytecode instruction to its native counterpart. This increases the execution time for Java programs, thereby affecting their performance. Therefore, to improve the performance of Java programs, the number of times the bytecode instruction is converted to machine code by JVM interpreter needs to be reduced. Note that the security aspect of the Java programs is attributed to the bytecode and the class file format. These collectively allow you to run your Java programs on any JVM and also test the code for safety. The bytecode should be translated to native machine code only after the class files are loaded and verified. Either the class files, as a whole, can be translated into machine code after being loaded and verified, or only the methods required currently can be converted to machine code. If class file, as a whole, were translated to

67

68

Part I


machine code, it would reduce the performance of the Java program. This is so because some methods in the class file may not be executed and the time taken for their conversion to native machine code would be wasted. Therefore, the second option of translating only the methods that need to be executed sounds better as it would improve the program performance. This process of translating bytecode to machine code as and when required is called JIT compilation. JIT compilers are very effective because they compile only the code that is actually executed. Therefore, the methods that are executed frequently can be retrieved from the native method area and executed on the fly. This process occurs during runtime. 2. A currently executing Java application also needs data areas for the native methods. There are very few security restrictions for native methods. Thus their capabilities are not limited. Native methods can use runtime data areas such as registers, stacks, or heaps for memory allocation. They are implementation-dependent, and the designers can decide how a native method will be invoked in a running Java application. When a running program invokes a native method, JVM directly links to the method instead of pushing the necessary information on to the stack. A native method interface uses a native method stack for locating and loading native methods in JVM. For example, assume that the native method interface uses the C language. Then, the native method stacks would be C stacks. The native method stacks in this implementation can contain function parameters and return values. Therefore, the implementation of the native method interface and the native method stack is entirely designer-dependent. 3. Garbage collection refers to the process of releasing the memory held by objects once they are destroyed or are no longer needed in the program. This implies that the memory held by an object that is no longer needed in the program is recycled. Instead, this heap space can be used by another object. The garbage collector is also involved in heap fragmentation. When a program is still executing, the objects that are being cleared by the garbage collector leave free blocks of heap memory between the memory spaces already occupied by active objects. Assume that an object that needs to be allocated requires less memory space than the total free memory in the heap. However, this memory space is not present in continuous memory locations, indicating a need to increase the memory size of the heap. This can affect the performance of a currently running program.

Chapter 4 Class Files

Y

ou are already clear about the fact that the various popular features of Java such as platform-independence and security can be attributed to the Java bytecode rather than to the Java source code. In the preceding chapters, you have learned that the compilation of the Java source code results in the generation of bytecode. In this chapter, I’ll discuss mainly the development and format of class files, which are generated in the last stage of the development process. First, let’s discuss the compilation process in Java, which results in the creation of class files.

The Compilation Process During compilation, a Java source program that is written in a high-level language is converted to bytecode, which is in a machine-level or low-level language. A Java source program may contain multiple class definitions. During compilation, all these class definitions are stored in a single class file. Now, this Java source program may even contain method calls to different classes that are defined elsewhere. Therefore, the class file generated contains references to these classes in addition to the machine code derived after compilation. The generation of the class file is the last step in the development environment. You might be wondering whether there is a separate linking phase to solve the inter-class references. No, there is no separate linking phase, and the JVM loads the referenced files as and when needed during runtime. However, this dynamic linking process requires that the class file contain the names of the referenced classes along with the name of the methods and fields of the classes that are being used in the Java source program. For a particular Java source code, you need not have only one bytecode after compilation. This means that you can generate bytecode without the Java source code also. Every program written in Java is compiled into bytecode; however, you can also create class files or produce bytecode without using the Java compiler. This bytecode generated by external methods can also pass through the integrity check performed by the class verifier. Therefore, these deviant class files can be easily created and run in the JRE. You must have guessed by now the security threats caused by this. This inconsistency between the Java source code and its respective bytecode is an obvious loophole in the basic security implementation of Java. Let’s understand what goes into a class file that makes it susceptible to hacker attacks. The next section discusses the class file format.

CLASS FILES

Chapter 4

The Class File Format in Java 2 Each class file in Java contains at least a Java class or an interface. The class file format is presented in the form of pseudo-structures that can be compared to the structures in C. The contents of these structures are referred to as items. The class file data is marked by u1, u2, and u4 types. These types indicate unsigned one-, two-, and fourbyte quantities. A class file contains a single ClassFile structure, which is given here: ClassFile { u4 magic; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info constant_pool[constant_pool_count-1]; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; }

Let’s discuss the various items of the ClassFile structure. ◆ The magic item represents the magic number that identifies a class file. It has the default value, 0xCAFEBABE. ◆ The minor_version and major_version items represent the minor and

major version numbers of the compiler that created the specific class file. For example, assume that the JVM implementation supports a particular major version number and the code to be run has a different major version. This difference in major version numbers indicates a high incompatibility issue that requires a different implementation of the JVM. ◆ The constant_pool_count item represents the number of entries in the constant_pool table of the class file. An entry in this table is marked by the constant_pool index. The valid entries of this index are between zero

71

72

Part I


and the constant_pool_count value. The entry at index zero is included in the count. However, it is not included in the constant_pool table of the class file. ◆ The constant_pool table is an array containing heterogeneous structures such as the class names, field names, and constants specified in the ClassFile structure. The first entry in the class file is marked as constant_pool [1] because the entry at index zero is used for internal purposes by the

JVM. You will read more about the constant pool in the subsequent section. ◆ The value of the access_flags item represents the modifiers for the class and interface declarations. For example, the ACC_PUBLIC access flag is used

by classes and interfaces to represent that they are public and can be used by elements that are external to their package. Alternatively, the ACC_FINAL access flag cannot be set for interfaces because their implementation would otherwise never be complete. Therefore, this access flag is set only for the classes that do not want any subclasses to be derived from them. ◆ The this_class item represents a class or interface defined in the specified class file. The value of this item is a valid element of the constant_pool

table. ◆ The super_class item represents the superclass of the class defined in the

specific class file. The value of this item may be zero or a valid entry in the constant_pool table. If the value is zero, it indicates that the specified class

in the class file has no superclass; otherwise the value of this item represents a constant_pool entry specifying the superclass of the class in the class file. Keep in mind the fact that a superclass cannot be final. ◆ The interfaces_count item gives the total number of super interfaces for

the specific class or interface. ◆ The interfaces[] item is an array of the interface implemented by the

specified class in the class file. Each value of the array should be a valid index in the constant_pool table. ◆ The fields_count item represents the number of field_info structures in the fields table. These structures represent the fields contained in the class

and the instance variables for the specified class in the class file. ◆ The fields[] array item contains the field_info structures for all the

fields specified in the class or interface definition. It does not specify the fields that are inherited from superclasses or interfaces. ◆ The methods_count item represents the number of method_info structures in the methods table. These structures represent the methods contained in the class. They also specify the init() method of the instance variables for

the specified class in the class file.

CLASS FILES

Chapter 4

◆ The methods[] array item contains method_info structures for the methods

specified in the class. These structures also represent the JVM code for the class methods. ◆ The attributes_count item specifies the number of attributes in the attributes table of the class. ◆ The attributes[] array item contains all the attributes contained in the

class file. The JVM can ignore the attributes that it does not recognize. The only attribute defined for the attributes table is the SourceFile attribute. This attribute specifies the name of the source file from which the class was created. There can be only one SourceFile attribute in the attributes table. In addition to the previous elements, the class file also contains tables for interfaces, fields, methods, and attributes. A 2-byte number specifying the number of entries contained in the table precedes each table. Each entry in a particular table has a structure type specified by the table. The methods table is the most important of them all because it contains the bytecode that is executed on the JVM. The methods table contains entries that are structures of the type, method_info. The code for this structure follows: method_info { u2 access_flags; u2 name_index; u2 descriptor_index; u2 attributes_count; attribute_info attributes[attributes_count]; }

I discussed previously that the constant_pool table contains heterogeneous structures within it. Let’s discuss the contents of the constant pool in detail.

The Constant Pool The constant pool acts as a symbol table for linking during runtime and a data store for the constants and literal values contained in the source code. It is an array that is referenced through index numbers from the other sections of the class file, such as the field and method sections. All the entries in the constant table have the following basic format. cp_info { u1 tag; u1 info[]; }

73

74

Part I


Each entry in the table begins with a 1-byte tag that describes the kind of information stored in the entry. Table 4-1 describes the types and values of the entries stored in the constant pool. Table 4-1 Types and Values of the Constant Pool Entries Type

Value

Class

7

Fieldref

9

Methodref

10

InterfaceMethodref

11

String

8

Integer

3

Float

4

Long

5

Double

6

NameAndType

12 1

Utf8

Let’s discuss each of these types in detail.

Class The Class structure is used to represent a class or interface and can be described by the following code: CONSTANT_Class_info { u1 tag; u2 index; }

The tag item of the previous structure takes the value of the Class structure; 7. The value of the index entry is a valid index of the constant_pool table.

Fieldref, Methodref, and InterfaceMethodref The Fieldref, Methodref, and InterfaceMethodref constant types are described by the following code structures. These types are a symbolic reference to a field, a method, and an interface method, respectively.

CLASS FILES

Chapter 4

CONSTANT_Fieldref_info { u1 tag; u2 class_index; u2 name_and_type_index; } CONSTANT_Methodref_info { u1 tag; u2 class_index; u2 name_and_type_index; } CONSTANT_InterfaceMethodref_info { u1 tag; u2 class_index; u2 name_and_type_index; }

The tag item in these code structures takes the value described in Table 4-1. The value of the class_index item is a valid index of the constant_pool table. The entry at the specified index is a CONSTANT_Class_info structure describing the class or interface containing the specified field or method. Therefore, the class_index item of the Fieldref or Methodref structure must be a class type, whereas the class_index item of the InterfaceMethodref structure must be an interface type. The name_and_type_index entry represents the name and descriptor of the specified field or method.

String The String type is used to represent constants of the java.lang.String type. This type is represented by the following structure: CONSTANT_String_info { u1 tag; u2 string_index; }

The tag item of this structure takes the value of the String type— 8. The string_index item represents the characters to which the java.lang.String object is initialized.

75

76

Part I


Integer and Float The Integer and Float items represent 4-byte numeric constants of the int and float types. These items are represented by the following code structures. CONSTANT_Integer_info { u1 tag; u4 bytes; } CONSTANT_Float_info { u1 tag; u4 bytes; }

The tag items of the Integer and Float structures take the values of 3 and 4, respectively. The bytes items of both these structures contain the value contained in the int and float constants.

Long and Double The Long and Double types represent the 8-byte numeric long and double constants. They are represented by the following code structures. CONSTANT_Long_info { u1 tag; u4 high_bytes; u4 low_bytes; } CONSTANT_Double_info { u1 tag; u4 high_bytes; u4 low_bytes; }

The tag items of the Long and Double structures contain the values 5 and 6, respectively. The high_bytes and low_bytes items of both these structures collectively represent the value contained in either the double or long constant.

CLASS FILES

Chapter 4

NameAndType The NameAndType structure can be used to represent fields and methods without indicating the name of the class or interface to which they belong. The code for this structure follows: CONSTANT_NameAndType_Info { u1 tag; u2 name_index; u2 descriptor_index; }

The tag item defined in this structure contains the value 12. The name_index item represents the names of the fields and methods that act as Java identifiers. The value contained in this item is not a fully qualified name; however, it is used to recognize the concerned fields and methods in a program. The descriptor_index item represents a valid Java descriptor for fields and methods.

Utf8 This constant type is used to represent constant string values in the Utf8 format. In the Utf8 format, the strings containing non-null ASCII characters are represented by using only one byte per character. The strings represented in this format are not nullterminated. However, characters of up to 16 bits can be represented. This type is represented by the following code structure: CONSTANT_Utf8_info { u1 tag; u2 length; u1 bytes[length]; }

The tag item contains the value 1. The length item represents the number of bytes in the bytes array. The bytes array has the number of bytes contained in the string. Therefore, looking at the description of the previous items, I can summarize that a class file contains information regarding the classes contained within it. It also contains information regarding the JVM implementation for the specified class file. Further, the class file contains specific information, such as the fields, attributes, methods, interfaces, or subclasses for the classes defined within it.

77

78

Part I


However, all the previous information contained in a class file poses a risk to security, because hackers can use it to tamper with your system. The next section discusses the security threats posed due to class files.

Decompilation Threats All the detailed information available in a class file enables a hacker to derive the Java source code, although this process is not very easy. The tool needed for this purpose is a decompiler that converts Java bytecode to the original source code. In other words, it undoes the work done by the compiler. The decompilation process is also referred to as reverse engineering. You can use the Mocha decompiler to decompile class files into source code. Compilers generally render it ineffective for converting machinelevel language to high-level language because they remove a lot of additional information such as the variable and function names. This information is needed by decompilers to perform their tasks. In case of the java compiler, the only information lost during compilation are the comments, which cannot be retrieved by the Mocha decompiler. However, the variable and method names are self-explanatory and their functionality can be understood even without comments. Although the code generated by the Mocha decompiler is not completely similar to the Java source code, it is easily understandable and can be modified. Let’s take an example to understand the decompiling process by the Mocha decompiler. Consider the following code: import java.io.*; public class test{ public static void main(String args[]) { System.out.println(“Testing the MOCHA Decompiler”); } };

Compile this code by executing the following statement: javac test.java

On execution, this command generates the test.class file, which I’ll decompile using the Mocha decompiler. You can run the decompiler by using the following code statement: java mocha.Decompiler test.class

This code statement generates the test.mocha file and places it in the same directory as the class file. Figure 4-1 displays the test.mocha file as seen in Notepad.

CLASS FILES

Chapter 4

FIGURE 4-1 The test.mocha file in Notepad

Even though the code in the test.mocha file is not exactly similar to the source code, it is easily understandable. Therefore, hackers or even Java developers can use this decompiler to leak out business secrets or decompile a competitor’s project, respectively. However, a hacker need not go into this tedious task of decompiling class files, changing the source code, and then again compiling them to obtain the corrupted class files. A person who has substantial knowledge of Java and class file format can easily update, insert, or delete code in the class files. These changes are done smartly so that the class file verifier does not identify them.

Benefits of Decompilation The decompiler is not just used by hackers for malicious purposes. You can, in turn, use it for several important reasons. For example, imagine that you delete the source code for a Java program by mistake. However, you still have the compiled class file for the particular source. Then, you can use the decompiler to recover the lost Java source code. There are more reasons for you to use the decompiler, some of which are specified here. You can refer to the source code of your development partner who is creating a Java project with you. Decompilers can also be used to check the validity of the Java class files that you receive from an unknown source. It is morally and legally acceptable to use a decompiler on your own programs. However, it is not so if you use it to decompile someone else’s programs or steal the source code of copyrighted programs.

79

80

Part I


You might be wondering how to protect your Java code from the aforementioned decompiler threats. The next section discusses just that.

Preventing Decompilation Threats One method to restrict reverse engineering of bytecode is to control physical access to the program. Users accessing the program may need to interact with an interface with minimal number of services. However, this client-server model may affect program performance due to network limitations. Decompilers look for recognizers in the Java class file, using which they can easily translate the bytecode to its corresponding source code. As you have read in the preceding sections, such information is not hard to decipher, looking at the amount of detailed class file information contained in the constant pool. You have seen that information such as class, field, and method references are very readily available from the constant pool. Hackers can easily use this information for malicious purposes. You cannot completely erase the threat of decompilation; however, it can be reduced to a large extent. I’ll discuss the various protection techniques against decompilation in the subsequent sections.

Code Obfuscation You can make the source code difficult to read so that no one can decipher it easily. This technique is known as code obfuscation, which refers to confusing the reader by hiding important details. This is generally done by removing comments from the code. This is what Mocha does too. However, the reader can recognize the functionality of the various methods and fields by reading their meaningful names. You need not worry as you can also replace variable and method names by meaningless characters using the code-obscuring techniques. Therefore, this technique retains the compatibility of the source code in the Java environment, although the source code is not easily decipherable by human readers. This does not, however, indicate that your code is protected from all human readers. There might be some smart hackers who might still succeed in deciphering this obscured code. This risk always remains. To protect Java bytecode from reverse engineering, you can apply a bytecode obfuscator on the specified class files. Crema is one such example of a Java obfuscator. The same author who released Mocha, the decompiler, released Crema. Crema scrambles the symbolic reference information available in class files, such as the references to the field or methods of a specified class. This makes a class file less vulnerable to decompilation. For example, Crema scrambles class, interface, superclass, fields, and method names. You might be wondering how the JVM will link to the library packages if these symbolic references are missing in a class file. Do not worry, as Crema scrambles the references but rearranges them in such a way that the JVM still functions

CLASS FILES

Chapter 4

correctly. Now, if this code were decompiled using Mocha, it would raise exceptions, as it would be confused by the jumbled symbolic references, thus rendering reverse engineering difficult. However, as discussed earlier, this cannot stop determined hackers from achieving their evil goals.

Bytecode Hosing Another software that helps in suppressing reverse engineering is HoseMocha. HoseMocha is a bytecode hoser utility that appends extra instructions after a return instruction in the source code. For example, it splits the bytecode into different instruction sequences such as a PUSH operation followed by a POP operation. However, hackers can also suppress this technique. When the bytecode that has been hosed is decompiled, it results in readable code but it is spread with misleading passages. It is more readable than code after obfuscation. There is another serious implication in the use of bytecode hosers such as HoseMocha. They affect the performance of JIT compilers. You already know that JIT compilers are used to improve the performance of Java programs by reducing the interpretation overhead. JIT compilers read patterns in the bytecode, which can be converted to native code. Now, if you rearrange these patterns by using a bytecode hoser, you make the task of the JIT compiler difficult.

Salting Salting code refers to the process of inserting non-functional code or eccentric symbols to the Java source code. Therefore, salting makes a code difficult to decipher. An example of code insertions can be intentional loops inserted by the programmer. These code insertions compile correctly in the program; however, they do not affect the functionality of the program. Salting can cause unforeseen bugs to creep into your programs thereby affecting its overall performance. It can also be used as a technique to guard code from copyright issues. Moreover, these techniques do not completely safeguard you from decompilation techniques. Therefore, it is the task of developers to ensure that they do not transmit sensitive data such as passwords or private cryptographic keys in a class file. This is a serious risk in the client-server architecture where data is transferred from a server to a client and vice versa. Java 2 provides tools to store classes in JAR files, which are then transmitted across the network. Client-server applications need a much more secure server-side where sensitive data can be stored. All these tools do not completely suppress the risk of attacks to sensitive data. However, they make the task of reverse engineering less feasible in terms of time and money. The most you can do is to store the sensitive data under legal and copyright laws.

81

82

Part I


You have read so much about bytecode that you must be keen to explore the intricacies of bytecode instructions. The next section discusses the Java bytecode in detail.

Java Bytecode: Basics You must already be clear about the fact that the Java source code, when compiled, is not converted directly to machine code. Instead, it is converted to an intermediate bytecode format, which is, in turn, executed by the JVM. There may be a few Java developers who might have seen this intermediate bytecode due to the limitations of the tools being used by them. However, the Java SDK provides you with an assembler, javap, which converts the bytecode to a human-readable format. This is a command-line tool that examines the constant pool and other contents of the class file and produces a readable version of the bytecode contained in the class file. Let’s observe the functionality of the javap tool by reviewing the following Java source code. public class javapTrial { public static void main (String[] args) { System.out.println(“This is a trail of the javap command”); } }

After the class is compiled, the generated .class file can be disassembled by using the javap command utility. This converts the class file into mnemonics that can be interpreted by human readers. You will use the following command to perform the disassembling process. javap -c javapTrial

Figure 4-2 displays the output of this command. Let’s try to understand the output displayed in Figure 4-2. I’ll first consider the main method, as follows: Method void main( java.lang.string[]) 0 getstatic #2 3 ldc #3 <String “This is a trial of the javap command”> 5 invokevirtual #4 <Method void println(java.lang.String)> 8 return

CLASS FILES

Chapter 4

FIGURE 4-2 Output of the javap command

The initial integer before the instructions in the methods represents an offset of the instruction in the method definition. Therefore, the first instruction starts with 0. The offset is followed by the mnemonic of the instruction. The first instruction, getstatic, pushes a static field on to a data structure called an operand stack. The instructions following the specified instruction can pick the field from the data structure and use it in their computations. After the getstatic instruction, you can see the reference number, #2, which indicates the field to be pushed to the stack. In this case, the field to be pushed is java.io.PrintStream out. However, this field information is not directly visible in the bytecode. Instead the bytecode contains a reference to the particular field. This field information is stored in the constant pool, thereby reducing the size of the bytecode instructions. Therefore, the number#2 indicates that field information is stored at location #2 in the constant pool. Now, as you have analyzed the first statement, the interpretation of the remaining statements becomes comparatively easy. The next instruction follows: 3 ldc #3 <String “This is a trial of the javap command”>

The ldc instruction is also referred to as the load constant instruction. It pushes the string constant, “This is a trial of the javap command”, to the operand stack. Finally, the invokevirtual instruction invokes the println method. This method requires two arguments, the string argument and the this reference, which are, in turn, popped from the operand stack. The bytecode instructions can be divided into few basic categories: ◆ Pushing constants onto the operand stack ◆ Accessing arrays ◆ Stack manipulation through PUSH and POP instructions

83

84

Part I


◆ Arithmetic and logical instructions ◆ Control transfer or return ◆ Invoking methods ◆ Creating objects

You must have noticed that even at the bytecode level there are references to the fields and methods available in the source program. This indicates that Java bytecode is also object-oriented. You might be wondering about the differences in Java bytecode and assembly language code. Even though the functionality of the two is almost similar, there are certain design differences in them. The JVM works under a stack architecture, where values are pushed into or popped from a stack. Alternatively, the assembly language processor has a register-based architecture, where the values are stored into temporary memory locations called registers. Comparing the two architectures, the stack-based architecture is easier to implement and port to different platforms. Moreover, understanding the functionality of the code is much easier in the stackbased architecture. As already discussed, the Java bytecode is object-oriented, making it easier for the JVM to check for method or field type discrepancies during runtime. Alternatively, in assembly language processors, the object-oriented features of the high-level language are lost when the program is compiled. This fact leads to security loopholes because the runtime engine cannot check for validity issues in field and method references. Therefore, type safety is an important feature for implementing security.

Type Safety Java programs look very similar to C++ programs; however, Java programs implement security whereas C++ programs don’t. This is due to the prevention of memory bugs by the Java bytecode. Memory bugs are a very important aspect towards attacking an otherwise safe code. For example, consider a very simple Java program that adds a float and an integer number. public class addNumber { public float add(float c, int d) { return c+d; } public static void main (String[] args) { int a = 10; float b = 2;

CLASS FILES

Chapter 4

addNumber num=new addNumber(); System.out.println(“The sum of the numbers is”+ num.add(b,a)); } }

When this program is compiled and disassembled by using the javap command, the output bytecode is as shown in Figure 4-3. Let’s consider the bytecode for the add method. It is listed here. Method float add(float, int) 0 fload_1 1 iload_2 2 I2f 3 fadd 4 freturn

Before executing a Java method, the JVM stores the method parameters in a data structure. Therefore, if we consider this method, there would be three entries in the respective data structure, namely, the this reference, the float parameter, and the integer parameter. To further edit these parameters, they need to be placed on the operand stack.

FIGURE 4-3 The bytecode for the addNumber.class file

85

86

Part I


Therefore, the instructions, fload_1 and iload_2, load the float and integer parameters to positions 1 and 2 of the operand stack. The noticeable fact about these entries is that they start with an f and i prefix, respectively. This indicates that the bytecode instructions are strongly typed, which is another very important security feature of the JVM. Refer to Table 4-2 for the various types of prefixes allowed in the Java bytecode. Table 4-2 Java Bytecode Type Prefixes Type

Prefix

Integer

i

Float

f

Double

d

Byte

b

Long

l

Short

s

Character

c

Object Reference

a

During runtime, if the type of a parameter does not match its respective entry in the bytecode, the JVM rejects the bytecode as being unsafe. These type-safety checks are performed only during the class load time. Tampering with these type safety checks would lead to serious security implications. For example, if hackers succeed in blindfolding the JVM so that the JVM treats an integer as a float or vice versa, they could perform malevolent calculations such as tampering with an online bank application. Memory checks need to be implemented in case of array manipulation techniques. Bytecode instructions such as aaload and aastore operate on arrays and check the array memory bounds as well. If someone tries to exceed the memory bounds of an array, these instructions throw ArrayIndexOutOfBoundsException. Another area susceptible to attacks is branching instructions. However, there are certain limitations placed on branching instructions in Java bytecode, as follows: ◆ Branching instructions can only branch to instructions in the same method. ◆ Transferring instructions outside a given method is possible only with the return instruction or through the invoke instruction.

The point highlighted in the previous sections is that Java differs from the remaining object-oriented languages in the fact that it controls security on the compiled code, whereas the remaining languages, such as C++, avoid memory errors at the source code level.

CLASS FILES

Chapter 4

Considering the type safety of bytecode, you cannot conclude that this safety is available for all the viable Java bytecodes because not all bytecodes are typed. There is minimal type support in the JVM for byte and short values. Even these data types are not well supported in the constant pool. Moreover, the JVM processor stack is limited to 32 bits. Therefore, the JVM manages values longer or shorter than this by special instructions. Examples of such values are long, double, short, and byte. If the Java source code is being compiled to bytecode, the compiler takes care of these special instructions. However, you are already clear about the fact that bytecode can also be created without the Java compiler. In such cases, the permissible limits that these data types can take are not controlled. Due to the lack of one-to-one correspondence between the Java source code and its corresponding bytecode, a lot of work needs to go into verifying the bytecode being executed by the JVM. This is because the Java class verifier passes those class files as well that have not originated from pure Java source code. These class files may contain code not derived from a trusted source. Therefore, further checks need to integrated with the class file verifier to avoid such major security flaws in Java. The ease with which the deviant class files pass the class file verifier needs to be controlled.

Summary In this chapter, I discussed the compilation process in Java that results in the creation of class files, which is the major focus area in this chapter. Next, I discussed the class file format in Java 2. Then, I discussed the threats faced due to reverse engineering or decompilation. I also discussed the benefits of decompilation. You learned the techniques to prevent these decompilation threats. Finally, I discussed Java bytecode and the importance of type safety in detail.

Check Your Understanding Multiple Choice Questions 1. Which of the following constant pool entries is used to represent fields and methods without indicating the name of the class or interface to which they belong? a. NameAndType b. Utf8 c. String d. Integer

87

88

Part I


2. Which of the following refers to the technique of confusing the reader by hiding important details? a. Bytecode hosing b. Code obfuscation c. Salting d. Decompilation 3. Which of the following is not a category of bytecode instructions? a. Pushing constants onto the operand stack b. Accessing arrays c. Arithmetic and logical instructions d. Creating structures 4. Which of the following bytecode instructions operate on arrays? a. aaload b. getstatic c. aastore d. ldc 5. Which of the following tools converts the bytecode to a human-readable format? a. Mocha decompiler b. HoseMocha c. Assembler d. Crema

Short Questions 1. Explain the role of a decompiler. 2. Explain code obfuscation and bytecode hosing.

Answers Multiple Choice Answers 1. a. The NameAndType structure can be used to represent fields and methods without indicating the name of the class or interface to which they belong. 2. b. Code obfuscation refers to confusing the reader by hiding important details.

CLASS FILES

Chapter 4

3. d. The bytecode instructions can be divided into few basic categories, such as pushing constants onto the operand stack, accessing arrays, stack manipulation through PUSH and POP instructions, arithmetic and logical instructions, control transfer or return, invoking methods, and creating objects. 4. a and c. Bytecode instructions such as aaload and aastore operate on arrays and check the array memory bounds as well. 5. c. An assembler converts the bytecode to a human-readable format.

Short Answers 1. A decompiler converts Java bytecode to the original source code. In other words, it undoes the work done by the compiler. The decompilation process is also referred to as reverse engineering. You can use the Mocha decompiler to decompile class files into source code. Compilers generally render it ineffective for converting machine-level language to high-level language because they remove a lot of additional information such as the variable and function names. This information is needed by the decompilers to perform their tasks. In case of the java compiler, the only information lost during compilation are the comments, which cannot be retrieved by the Mocha decompiler. However, the variable and method names are self-explanatory and their functionality can be understood even without comments. Although the code generated by the Mocha decompiler is not completely similar to the Java source code, it is easily understandable and can be modified. Therefore, hackers or even Java developers can use this decompiler to leak out business secrets or decompile a competitor’s project, respectively. The decompiler is not just used by hackers for malicious purposes. You can, in turn, use it for several important reasons. For example, imagine that you delete the source code for a Java program by mistake. However, you still have the compiled class file for the particular source. Then, you can use the decompiler to recover the lost Java source code. Decompilers can also be used to check the validity of the Java class files that you receive from an unknown source. 2. Code obfuscation refers to confusing the reader by hiding important details. This is generally done by removing comments from the code. The reader can recognize the functionality of the various methods and fields by reading their meaningful names. You need not worry as you can also replace variable and method names by meaningless characters using the code-obscuring techniques. Therefore, this technique retains the compatibility of the source code in the Java environment, although the source code is not easily decipherable by human readers. This does not, however, indicate that your code is protected from all human readers. There might be some smart hackers

89

90

Part I


who might still succeed in deciphering this obscured code. This risk always remains. To protect Java bytecode from reverse engineering, you can apply a bytecode obfuscator on the specified class files. Crema is one such example of a Java obfuscator. The same author who released Mocha, the decompiler, released Crema. Crema scrambles the symbolic reference information available in class files, such as the references to the field or methods of a specified class. This makes a class file less vulnerable to decompilation. For example, Crema scrambles class, interface, superclass, fields, and method names. You might be wondering how the JVM will link to the library packages if these symbolic references are missing in a class file. Do not worry, as Crema scrambles the references but rearranges them in such a way that the JVM still functions correctly. Now, if this code were decompiled using Mocha, it would raise exceptions, as it would be confused by the jumbled symbolic references, thus rendering reverse engineering difficult. Another software that helps in suppressing reverse engineering is HoseMocha. HoseMocha is a bytecode hoser utility that appends extra instructions after a return instruction in the source code. For example, it splits the bytecode into different instruction sequences such as a PUSH operation followed by a POP operation. However, hackers can also suppress this technique. When the bytecode that has been hosed is decompiled, it results in readable code but it is spread with misleading passages. It is more readable than code after obfuscation. There is another serious implication in the use of bytecode hosers such as HoseMocha. They affect the performance of JIT compilers. You already know that JIT compilers are used to improve the performance of Java programs by reducing the interpretation overhead. JIT compilers read patterns in the bytecode, which can be converted to native code. Now, if you rearrange these patterns by using a bytecode hoser, you make the task of the JIT compiler difficult.

PART

II Advanced Java Security Concepts


Chapter 5 The Class Loader and the Class File Verifier

I

n the previous chapter, I discussed the class file format in detail and explained the advantages and disadvantages of the binary information contained in a class file. The class loader and class file verifier components of JVM form the core of the security implementation in Java. They work in collaboration to ensure the safe execution of Java programs. The class loader loads the specified class files in the Java program, whereas the class file verifier determines whether these class files are valid and safe for execution by JVM. In this chapter, I’ll discuss the working of the class loader and the class file verifier in detail.

Class Loaders: Basics You are already aware that class loaders are used to load classes in a running Java program. They guard the Java runtime environment by checking the bytecode being loaded so that the running Java code is not replaced by malicious code. The class loaders take care of this by separating the code downloaded from different sources and preventing the loading of untrusted classes. Class loaders mainly perform the following functions: ◆ They load the bytecode when requested by JVM. They have customized

methods to load bytecode either from the local disk or over the network. ◆ They define the namespaces for different classes and the relation between

these namespaces. ◆ They also define the set of permissions for loaded classes. Runtime access to

resources is based on these permissions. Therefore, the main function of class loaders is to load classes from different locations. However, it is not so simple as it sounds. Some considerations are necessary to enforce security while using the class loader. Let’s begin by discussing the class loader architecture in detail.

The Class Loader Architecture There is more than one class loader operating in JVM. JVM supports a flexible class loader architecture that loads classes in different ways. You are already aware that the classes loaded in a running Java program are from either trusted or untrusted sources.

THE CLASS LOADER AND THE CLASS FILE VERIFIER

Chapter 5

The trusted sources can be the Java API classes or the local file system, whereas the untrusted sources are external sources such as Web servers or the network. There are two types of class loaders, the primordial class loader and the class loader objects. These have been discussed in Chapter 3, “The Java Virtual Machine”. The primordial class loader is an integral part of the JVM implementation and is used to load trusted classes. Therefore, the classes loaded by the primordial class loader are not subject to verification. On the other hand, the class loader objects load untrusted classes in custom ways. Class loader objects are treated like any other Java object; they are created in Java, compiled into class files, and instantiated. Therefore, the classes loaded through the class loader objects are subject to the verification performed by the class file verifier. Due to the class loader objects, you need not keep track of which classes may be needed by a running program at the time of compilation. This can be done at runtime by the class loader objects.

Types of Class Loader Objects There are different types of class loader objects, as follows. ◆ Applet class loaders ◆ Secure class loaders ◆ RMI class loaders ◆ URL class loaders

The applet class loaders load classes into a browser and prevent the external classes from overriding the Java API classes. First, the applet class loaders try to load classes using the primordial class loader and only if the primordial class loader is unable to load the classes do they attempt to load classes from external sources such as the network or Web servers. If the primordial class loader is unable to load a class, the applet class loader loads the specified class via the HTTP protocol by using methods of the URL class. The specified code is searched for in the location mentioned in the CodeBase property, which is specified in the <APPLET> tag. If the class is still not found, a ClassNotFound exception is thrown. Passing the class-loading request to the parent class loader is an important feature of the parent-delegation model, which is discussed in a subsequent section. The property of class loaders that prevents external classes from overriding the Java API classes is a very important aspect for security implementation. For example, imagine an external SecurityManager class trying to replace the java.lang.SecurityManager class. This would mean trying to tamper with the security policy defined for the system, which contains the protection domain and the resource access permissions. This would cause a gaping hole in the security system.

95

96

Part II

ADVANCED JAVA SECURITY CONCEPTS

The secure and RMI class loaders are similar in function to the applet class loaders. They allow the primordial class loader to look for code before attempting to load it via external sources. The only difference is the location from where these class loaders can load classes. The secure class loader allows classes to be loaded from the directories specified in the java.app.class.path property. However, only the classes specified in the java.security package can use the secure class loaders. On the other hand, the RMI class loaders can load classes from the URL specified in the rmi.server.codebase property. The URL class loaders are used to load classes from URL search paths, which refer to both directories and JAR files. If a URL ends with a “/”, it signifies the reference of a directory; otherwise, it is assumed to refer to a JAR file. The classes loaded by the URL class loaders are by default granted the permission to access the URLs as specified in the URLClassLoader definition.

Namespaces You are already aware that there may be many class loaders running in a particular instance in JVM. However, the class loaders run in their own defined namespace. A namespace is a set of unique class names loaded by a specified class loader. The namespaces of different class loaders also overlap. Generally, JVM implementations employ different class loaders for loading code from different locations. In earlier versions of Java, the code loaded by similar class loaders was restricted by a single security policy. However, with the emergence of code signing, you could tag code with two distinct features, namely, the code origin (URL) and the code signer (the person who signed the code). The class loaders that load the specified code know about these code attributes. When applets are loaded from the network, the respective applet class loaders receive the binary information and instantiate this information as a new class. Because applets cannot define new class loaders, the applet class loaders only load the necessary code from the desired locations. The applet class loaders install the applets in different namespaces, which hide the details of an applet from the other applets. The advantage of this is that applets can have classes with similar names without it causing any name collision. When a class is transferred over the network, the applet class loader places it in a namespace, which also indicates the location from where the class was picked up. In a Java program, when one class references another, the applet class loader looks for the referenced class using a particular search pattern. It first searches in the classes loaded by the primordial class loader. If it is not found here, the applet class loader specifies the namespace of the class making the reference in its search criteria. This particular search pattern in which the built-in classes are searched first prevents imported classes from posing as built-in classes. For example, imagine an applet trying to gain access to the local file system by replacing the built-in I/O classes.


Chapter 5

A trusted Java application can define its own class loaders. However, this would be very risky in case of an untrusted applet, which could define its own namespace and trigger an attack on the Java security system. Therefore, you should be very careful while creating applications that define their own class-loading mechanisms. One drawback in the Java security model is that due to customized class loaders, the security model is distributed and cannot be controlled centrally. Therefore, while defining your own class loading mechanisms, you need to manage the namespaces associated with these class loaders as well.

Class Loader Hierarchies You are already aware that a JVM implementation can have multiple instances of class loader objects. You might be wondering that with so many instances of class loaders, which one should you actually use. Also, in Java 2, there are multiple class loader classes, all having unique features, which further complicates the issue. Java 2 implements a hierarchy of class loaders. Figure 5-1 shows the inheritance hierarchy of class loaders. You are already aware that there is only one primordial class loader and it cannot be overridden. The class loader class hierarchy starts with an abstract class, java.lang.ClassLoader, at its root. This class was defined in jdk1.0 and has been further refined across the various new version releases in Java.

FIGURE 5-1 Class loader hierarchy

97

98

Part II


In Java 2, the class, java.security.SecureClassLoader, is a subclass of the abstract ClassLoader class. Further, the class, java.net.URLClassLoader, is a subclass of the SecureClassLoader class. The Appletviewer uses a private class, sun.applet.AppletClassLoader. This class was a subclass of the ClassLoader class in jdk1.0. However, in Java 2, it is a subclass of the URLClassLoader class. As I have already discussed in the preceding section, you can create subclasses from any of these class loader classes to define a custom class loader. This depends entirely on your requirements defined for the custom class loader. However, the AppletClassLoader class is a private class, and therefore, you should not create subclasses from it. In the preceding sections, I’ve discussed the intricacies of class loaders with respect to the various classes in Java. Now, I’ll discuss the actual working of these class loaders.

The Class-Loading Mechanism In a running Java application, classes are needed when referenced by the currently running class. Once the main() method starts executing, the other referenced classes in the program are loaded by the class loader. It is the task of the class loader to create a namespace containing a set of class names, which includes the name of the class loaded and the classes referenced by this class. The class loader performs this function using the loadClass() method, whose definition is as follows. loadClass(String className, boolean resolveIt);

The className string represents the class to be loaded by the class loader. The resolveIt variable indicates whether a referenced class needs to be loaded. The primordial class loader uses the default implementation of the loadClass() method. Therefore, the code for a class loader searches the class path and the ZIP files for loading classes. It looks for the java.lang.Object class in the class path. Java can change the default implementation of a class loader by simply changing the set of functions that it implements. Therefore, you can also use user-defined class loaders. However, these are very powerful in the sense that they can replace the Java API core classes with their own version classes. Therefore, the classes most susceptible to these attacks—the applets—are not allowed to instantiate their own class loaders. Let’s discuss in detail how class loaders perform this function. The class loader instance invoked by JVM when a class is referenced checks whether the class has been previously loaded. If the class has been loaded previously, the class loader checks with the security manager whether the program has the permission to access the specified class. Therefore, the class loader works in coordination with the security manager in all the class-loading phases. If the security manager denies access to a particular class, a security exception is raised.


Chapter 5

If the referenced class has not been loaded earlier, the class loader checks for the specified class in the Java API core classes and the JVM extensions. This check prevents the core classes from being replaced by external classes from other sources. The core and extension classes are loaded by the built-in class loader, which is the primordial class loader. If the specified class is still not found, it is concluded that the class does not belong to a trusted source. Now, the class loader can look for the particular class in two possible locations. First, it can look for the class in the application class path that is set by using the CLASSPATH environment variable. Second, it can look for the class in the network. However, the bytecode from both the previous locations needs to be verified by the class file verifier before the class object is created. Therefore, the class loader passes the bytecode to the class file verifier before creating an object of the particular class. If the verification test is not cleared, an exception is raised. A protection domain is set for the class object, which specifies resource access for the particular class. The main difference in the class loading mechanism of Java 2 and the earlier versions is the presence of a delegation model for loading classes. I’ll discuss this parent-delegation model in the subsequent section.

The Parent-Delegation Model In jdk1.2, there is a new parent-delegation model for class loaders. The class loaders created in the earlier versions of Java still work in jdk1.2; however, they do not take advantage of the parent-delegation model. When you create a user-defined class loader in jdk1.2, each such loader has a parent class loader associated with it. If a parent class loader is not passed explicitly to the constructor of the user-defined class loader, the system class loader takes on the role of the parent. When a new user-defined class loader is created, the parent loader is passed to the constructor. On the other hand, if an existing user-defined class loader is passed to the constructor of a new user-defined class loader, this user-defined class loader becomes the parent of the new loader. I’ll explain the parent-delegation model using the following example. Consider a Java application that creates a user-defined class loader called GrandMother. However, no class loader reference is specified in the constructor of the GrandMother class. Therefore, the primordial class loader becomes the parent of the GrandMother class loader. Further, the application creates another class loader called Mother and passes the reference of the GrandMother class loader in its constructor. Therefore, the GrandMother class loader is the parent of the Mother class loader. The application further creates a class loader called Daughter and passes the reference of the Mother class loader to its constructor. Therefore, Mother acts as a parent to the Daughter class loader. Therefore, a parent-child delegation chain is created with the primordial class loader at the top. Figure 5-2 depicts this parent-child delegation chain.

99

100

Part II


FIGURE 5-2 The parent-child delegation chain

The Java application requests the Daughter class loader to load a class named java.io.WriteFile. According to the parent-delegation model, the class loader first asks the parent to load the class. The parent further asks its parent to load the class and so on. Therefore, the delegation for loading the class reaches the top of the delegation chain, which is the primordial class loader. In the example, the Daughter class loader delegates class loading to the Mother class loader, which in turn delegates it to the GrandMother class loader. Finally, the GrandMother class loader delegates it to the primordial class loader. The primordial class loader loads the specified class and passes it down the chain through the GrandMother, Mother, and Daughter class loaders. The Daughter class loader further returns the loaded class to the requesting application. In Java, it is not the case that the class loader that initiates the class-loading activity is the same as the class loader that defines the specified class. For example, the class loader that is asked to load a class, although it passes this request to another class loader in the chain, is called the initiating class loader for the specified class. The class loader that actually defines the class is called the defining class loader for the specified class. In the preceding example, GrandMother, Mother, and Daughter are the initiating class loaders for the java.io.WriteFile class, whereas the primordial class loader is the defining class loader for the java.io.WriteFile class. Consider the case when a class that does not belong to the Java core API classes needs to be loaded. In this case, the application would again request the Daughter class


Chapter 5

loader to load this class. The class loading request would pass the parent-child delegation chain and reach the primordial class loader. However, because the specified class does not belong to the core Java classes, the control would be passed back to the GrandMother class loader. I’ll assume that the specified class belongs to a package that is present in the JAR files in the standard extensions directory. The GrandMother class loader, with its unique class loader method, is able to define the specified class. Therefore, the GrandMother class loader is the defining class loader, whereas the Mother and Daughter class loaders are the initiating class loaders. The primordial class loader is the default loader in a JVM implementation. However, you can also create user-defined class loaders by customizing the class loader methods. I’ll discuss more about the user-defined class loaders in the subsequent section.

User-Defined Class Loaders Creating a user-defined class loader is not always easy because you need to keep in mind certain rules and security measures while defining a new class loading mechanism. In Java 2, this process is simplified due to the delegation model discussed in the preceding section. There are four methods of the ClassLoader class that help you to interact with JVM for loading classes. The definition of these four methods is specified in the following code statements: protected final Class defineClass(String name, byte data[], int offset, int length); protected final Class defineClass(String name, byte data[], int offset, int length, ProtectionDomain protectionDomain); protected final class findSystemClass(String name); protected final void resolveClass(Class c);

These methods should associate with the internal class loader subsystem. Consider the previous code statements. Note that the defineClass() method is overloaded. It takes a byte data[] array as a parameter. This array can hold binary data for the class whose name is specified by the name parameter. The ClassLoader object accepts binary data and stores it in the array starting from the value specified by the offset parameter and continuing till the value contained in the length parameter. For the defineClass() method without the ProtectionDomain parameter, the default protection domain is assigned to the class defined. On the other hand, for the second defineClass() method, the class defined uses the protection domain as specified by the protectionDomain parameter. Therefore, the defineClass() method creates a new class and stores it in the method area of JVM.

101

102

Part II


The findSystemClass() method contains a String parameter, name, which specifies the name of the class that needs to be loaded. In jdk1.0 and 1.1, when a user-defined class loader invokes this method, it asks JVM to load the specified class via its bootstrap class loader. This method then returns a reference to the loaded class represented by the Class object. In jdk1.2, the findSystemClass() method tries to load the requested class by using the system class loader. Until now, the class loader has just loaded the classes in the method area. However, linking still needs to be performed, which is done via the resolveClass() method. This method takes an instance of the loaded class as a parameter and links it. Now, let’s understand the implementation differences between a jdk1.1 and jdk1.2 user-defined class loader.

Creating a Java 1.1 User-Defined Class Loader In jdk1.1, user-defined class loaders allowed you to load classes from all types of locations. A user-defined class loader just needs to implement the loadClass() method of the abstract class, java.lang.ClassLoader. However, it is not that simple. This method needs to perform a list of functions in case of a user-defined class loader. For example, a user-defined loadClass() method needs to check whether the class has been already loaded and whether it has been loaded by the primordial class loader. If the class has not been loaded, it has to be loaded from the specified repository, defined, and finally returned to the application that requested for it. Therefore, you need to consider all these functions for just loading classes to JVM. The design of the ClassLoader class does not provide facilities for the previous functions. If you think that you just need to define the function of class loading in a different way in the user-defined class loader, you are wrong! You need to define all these functions in a user-defined class loader as well. Let’s examine a user-defined class loader, myClassLoader, whose code listing follows. import java.io.*; import java.util.Hashtable; public class myClassLoader extends ClassLoader { // The myPath string marks the path, which myClassLoader follows to get the //

full path name of the class file, which is to be loaded private String myPath;

// Constructor public myClassLoader(String myPath) {


Chapter 5

this.myPath = myPath; } public synchronized Class loadClass(String className, boolean resolveIt) throws ClassNotFoundException { Class findResult; byte classBinData[]; // Check whether the specified class has already been loaded //

in the loaded class cache

findResult = findLoadedClass(className); if (findResult!= null) { // Return a reference to the stored class return findResult; } // Check whether the class is a system class with the primordial class // loader by using the findSystemClass() method try { findResult = super.findSystemClass(className); // Return a reference to the system class return findResult; } catch (ClassNotFoundException e) { } // Prevent the overwriting of a system class by an external class. // Attempting to load system classes only through the // primordial class loader can do this. if (className.startsWith(“java.”)) { throw new ClassNotFoundException(); } // Try to load it from the basePath directory. classBinData = loadClassFrommyPath(className); if (classBinData == null) { System.out.println(“Cannot load class: “ + className);

103

104

Part II


throw new ClassNotFoundException(); } // Store binary data of the class file in the byte array. findResult = defineClass(className, classBinData, 0, classBinData.length); if (findResult == null) { System.out.println(“Error in class format: “ + className); throw new ClassFormatError(); } if (resolveIt) { resolveClass(findResult); } // Return class from myPath directory return findResult; } private byte[] loadClassFrommyPath (String className) { FileInputStream myStream; String myFile = myPath + File.separatorChar + className.replace(‘.’, File.separatorChar) + “.class”; try { myStream = new FileInputStream(myFile); } catch (FileNotFoundException e) { return null; } BufferedInputStream myBuffStream = new BufferedInputStream(myStream); ByteArrayOutputStream myOutStream = new ByteArrayOutputStream(); try { int a = myBuffStream.read();


Chapter 5

while (a != -1) { myOutStream.write(a); a = myBuffStream.read(); } } catch (IOException e) { return null; } return myOutStream.toByteArray(); } }

Let’s go over the preceding code. The myClassLoader class declares a string variable, myPath, which stores the path of the directory where the class loader looks for the specified class that needs to be loaded. First, the loadClass() method checks whether the specified class has already been loaded. This method, in turn, calls the findLoadedClass() method. The specified class name is passed as a parameter to this method, which returns the class if it is located in the local cache. JVM maintains a list of the class names that have been loaded by each class loader. This list contains the class names stored in a class loader’s namespace. Before a class is loaded, this internal list maintained by JVM is checked for the specified class name. Therefore, the class loader uses the loadClass() method to load the specified class initially. The next time, the class loader calls the findLoadedClass() method to search for the class in the internal list of JVM. If the specified class is not loaded in the class loader’s namespace, the loadClass() method checks whether the specified class is a system class. It does this by passing the class name to the findSystemClass() method. The method listing is as follows: // Check whether the class is a system class with the // primordial class loader by using the findSystemClass() method try { findResult = super.findSystemClass(className); // Return a reference to the system class return findResult; } catch (ClassNotFoundException e) { }

105

106

Part II


In jdk1.1, the findSystemClass() method uses the primordial class loader that attempts to load the specified class. If the specified class is found, the findSystemClass() method returns the class, which is further returned by the loadClass() method. If the class is not found, the loadClass() method checks whether the specified class is a part of the Java API core classes by the following code: if (className.startsWith(“java.”)) { throw new ClassNotFoundException(); }

This check is very important because it prevents the internal Java classes from being overwritten by the user-defined class loader. After performing all these checks, the class loader tries loading the class through its customized implementation. The myClassLoader class does this by calling its loadClassFrommyPath() method. The method code follows: // Try to load it from the basePath directory. classBinData = loadClassFrommyPath(className); if (classBinData == null) { System.out.println(“Cannot load class: “ + className); throw new ClassNotFoundException(); }

// Store binary data of the class file in the byte array. findResult = defineClass(className, classBinData, 0, classBinData.length); if (findResult == null) { System.out.println(“Error in class format: “ + className); throw new ClassFormatError(); }

if (resolveIt) { resolveClass(findResult); }

// Return class from myPath directory return findResult; }


Chapter 5

The loadClassFrommyPath() method searches for the specified class followed by a .class extension in the directory specified by the myPath variable. If the class is not found, the loadClassFrommyPath() method returns a null value. The loadClass() method throws a ClassNotFoundException. If the class is found, the defineClass() method is invoked, which translates the binary class data into internal data structures. These data structures finally create the specified Class instance. Finally, the resolveClass() method is called, which links the Class instance defined by the defineClass() method. You can test this user-defined class loader by creating a test application. The code for this application is specified here: public class TestApp{ public static void main(String args[]){ try{ myClassLoader cl=new myClassLoader(“c:\\”); Class l=cl.loadClass(“myClassLoader”); System.out.println(“Loaded” +” “+l); }catch(Exception e){}

} }

The preceding application creates an instance of the myClassLoader class and tries loading the class file of this class itself. The output of this application is shown in Figure 5-3. Let’s observe the variations of this class loader implementation in jdk1.2.

FIGURE 5-3 The output of the TestApp.java program

107

108

Part II


Creating a Java 1.2 User-Defined Class Loader In jdk1.2, the delegation model is followed for the java.lang.ClassLoader class. As discussed in the parent-delegation model, the custom class loader delegates the class loading request to its parent class loader. The parent class loader calls the findClass() method. Therefore, the custom class loader loads only the classes that cannot be loaded from the parent repository. In jdk1.2, the custom class loaders do not override the loadClass() method; instead, they override the findClass() method, which contains the custom class loading logic. The definition of the findClass() method is as follows: protected Class findClass (String className) throws ClassNotFoundException

The findClass() method accepts the name of the class to be loaded as its parameter. This method attempts to locate or produce an array of bytes that defines the specified class. If the attempt fails, the findClass() method raises a ClassNotFoundException. If the class is found, the findClass() method invokes the defineClass() method, passing the class name, the array of bytes, and a ProtectionDomain object as parameters. The defineClass() method returns the Class instance for the specified class. Let’s observe the following code, which overrides the findClass() method. import java.io.*; public class myClassLoader extends ClassLoader { // The myPath string marks the path, which myClassLoader follows to get the // full path name of the class file, which is to be loaded private String myPath; // Constructor public myClassLoader(String myPath) { this.myPath = myPath; } public myClassLoader(ClassLoader parent, String myPath) { super(parent); this.myPath = myPath; } protected Class findClass(String className) throws ClassNotFoundException {


Chapter 5

byte classBinData[]; // Attempt to load the specified class from the myPath directory. classBinData = loadClassFrommyPath (className); if (classBinData == null) { throw new ClassNotFoundException(); } // Parse it return defineClass(className, classBinData, 0, classBinData.length); } private byte[] loadClassFrommyPath (String className) { FileInputStream myStream; String myFile = myPath + File.separatorChar+ className.replace(‘.’, File.separatorChar)+ “.class”; try { myStream = new FileInputStream(myFile); } catch (FileNotFoundException e) { return null; } BufferedInputStream myBuffStream = new BufferedInputStream(myStream); ByteArrayOutputStream myOutStream = new ByteArrayOutputStream(); try { int a = myBuffStream.read(); while (a != -1) { myOutStream.write(a); a = myBuffStream.read(); } } catch (IOException e) { return null; }

109

110

Part II


return myOutStream.toByteArray(); } }

Let’s examine and understand the preceding code. The myClassLoader class has two constructors. The one-argument constructor takes the myPath variable as a parameter. This variable stores the directory path in which the findClass() method looks for the specified class. This constructor invokes the superclass’s no-argument constructor, which sets the class loader’s parent to the system class loader. The two-argument constructor contains a reference to a user-defined class loader and the myPath string. Therefore, this constructor invokes the superclass’s one-argument constructor by passing the specified reference. Therefore, the superclass sets this class loader’s parent as the passed user-defined class loader instance. By using the delegation model, you can chain together multiple custom class loaders. The constructor for the java.lang.ClassLoader class lets you assign a parent class loader. Therefore, the class loading requests are delegated to the parent class loader. This leaves the child class loader with only the requests that cannot be fulfilled by the parent. If the no-argument constructor is chosen, the system class loader becomes the parent for delegation. If you compare the findClass() method with the loadClass() method defined in the jdk1.1 code, you would agree that it is much simpler to write the findClass() method than the loadClass() method. The findClass() method invokes the loadClassFrommyPath() method to load the requested class in this customized way. If the loadClassFrommyPath() method is unable to locate the requested class, it returns a null value and the findClass() method throws a ClassNotFoundException. If the loadClassFrommyPath() method locates the specified class, it returns an array of bytes, which the findClass() method passes to the defineClass() method. The defineClass() method returns a reference to the loaded class or it throws an exception. Therefore, the findClass() method uses just two parts of the loadClass() method: first, the custom method in which the array of bytes is located and loaded and second, the customized manner in which the protection domain for the specified class is defined. To summarize, the delegation design for jdk1.2 class loaders is an improvement over the earlier versions of the ClassLoader class. In the earlier versions, each ClassLoader subclass had to be retested for the class loading functionality. In other words, the logic intended for a superclass was put into a subclass instead. However, in jdk1.2, the code to implement the basic requirements of class loading need not be duplicated in the subclasses.


Chapter 5

The Class File Verifier The class file verifier works in association with the class loaders and checks the integrity of the loaded class files. The structure of class files is checked, and also whether they are consistent with the remaining class files. If the class file verifier encounters certain problems with the loaded class files, it raises an exception. You are already aware that class files can also be generated by other methods besides using the javac compiler. Because class files store just binary information, JVM cannot distinguish between a class file generated by the Java compiler and one generated by a hacker. This is the reason why all JVM implementations support a class file verifier to check that the class files created are safe for use. The main job of a class file verifier is to achieve program robustness. There are many cases when a buggy compiler or a cracker can affect the health of the JVM or a running Java program. A few of these cases are listed here. ◆ The number or type of parameters passed to a bytecode instruction is illegal.

This can lead to errors in executing the program or confusion in JVM because JVM cannot identify the correct class with the specified bytecode instruction. ◆ A class file contains illegal bytecode instructions. For example, imagine that

the compiler or a hacker generates an erroneous class file. This class file contains an instruction that causes the program to loop beyond the limit specified in a looping construct. This can cause the program to be suspended or even affect the JVM. It can even lead to a system crash or introduce a bug in the Web browser. The extent of damage caused by the instruction depends on the structure of the JVM execution engine. ◆ The class file contains instructions that cause an overflow or an underflow

of the stack. This can affect the memory management of JVM by exhausting its internal memory. The buggy class file can either pop more values to the stack than it has pushed or place more values than it has popped. ◆ Class files attempt to access the members of a class for which they do not

have sufficient access rights. In this case, an exception may be raised, and program execution will stop. This would most probably be caused by a hacker. JVM can control these cases, which are risks to program execution. It can check the stack after each bytecode instruction to remove the possibility of a stack overflow or underflow. It can also check the parameters passed to the bytecode instructions in a task. However, the previous tasks can be performed only at runtime, thereby affecting the performance of the running Java program. Therefore, it is advisable that the class file verifier catch these flaws before program execution begins.

111

112

Part II


The operation of the class file verifier is distributed across four different passes. In pass one, the class file verifier checks the internal structure of the loaded class file. It checks whether the class file is safe to parse. In passes two and three, the class file verifier checks the integrity of the bytecodes contained in the class file and checks the types against the rules and semantics of the Java programming language. These two passes occur during the linking phase of a Java program. Finally, pass four occurs during dynamic linking when the symbolic references are resolved. In this pass, the class file verifier verifies the symbolically referenced fields and methods of the classes in the program. I’ll now discuss the four passes in detail in the subsequent sections.

Pass One: Internal Structure Checks for Class Files During pass one, the class file verifier checks the binary information contained in the class files. The verifier performs the following checks in this pass: ◆ The class files should start with the four-byte magic number, 0xCAFEBABE.

This magic number helps the class file verifier identify whether the class files have been tampered with or created by a hacker for malicious purposes. The parser rejects the class files in which this number is missing or has been tampered with. ◆ The class file verifier checks that the minor and major version numbers in

the class file are consistent with the current JVM implementation. ◆ The class file verifier checks the length of the components of the class file,

thereby checking that the class file has not been truncated and no extra bytes have been added to it. The components contained in the class file specify their type and length, which are used by the verifier to calculate the total length of the class file. In pass one, the class verifier checks that the sequence of bytes that define a new type is as per the Java class file format. Once this check is performed, the bytes are translated into implementation-specific data structures in the method area. Therefore, the subsequent passes are performed on the internal data structures rather than the binary data in the class file format.

Pass Two: Class File Semantic Checks In this pass, the class file verifier checks the components of the class files to make sure that they follow the semantic rules of the Java programming language. For example, a method descriptor that consists of the return type and the number and type of parameters passed to the specified method is a string. Therefore, the class file verifier checks that all the method descriptors in the class file are a valid format for strings in Java. Certain constraints are placed on classes in the Java programming language spec-


Chapter 5

ification. It is the task of the class file verifier to check that the specified class follows these constraints. In addition, the class file verifier checks that no classes have been derived from the final classes and that the final methods are not overridden. The verifier also checks that the entries in the constant_pool table are valid and the indexes refer to the correct entries in the table. The big question is: “Why does the class file verifier perform these checks that are supposed to be performed at compile time by the javac compiler?” You are already aware that class files can also be generated in other ways besides using the Java compiler. However, the class file verifier has no way of differentiating between these files because both contain binary information. What happens if a hacker has generated a particular class file intentionally? Therefore, the class file verifier needs to perform the checks described previously to confirm that the rules of the language have been followed.

Pass Three: Bytecode Check In this pass, the class file verifier checks the bytecodes contained in class files. In this pass, the class file verifier is called the bytecode verifier instead. JVM performs a data check on the bytecodes that represent the methods of a specified class. The Java methods are represented as bytecode streams that consist of many 1-byte instructions called opcodes. These opcodes are followed by one or more operands, which provide additional data to JVM to execute a specified opcode instruction. Bytecodes represent a thread of execution in JVM, and each such thread has a stack, which contains frames. When a method is invoked, the specified bytecode gets its own frame, which is a memory area where the method can store information such as parameters or the result of an intermediate computation. An operand stack is that part of the frame that contains the result of an intermediate computation. Therefore, when JVM executes an opcode, it may need to constantly refer to the operand stack or the method frame that contains the parameters and local variables.

Bytecode Verifier Checks There are many checks performed by a bytecode verifier before executing a stream of bytecodes in JVM. A few of these checks are as follows: ◆ Irrespective of the way in which an opcode is executed, the operand stack

should always contain the same number and type of items. ◆ No local variable should be accessed before it is assigned a proper value. ◆ The class members, namely the fields and methods, should contain proper

values. The class fields should always be assigned values of the correct data types. The class methods should be invoked with the correct number and type of parameters.

113

114

Part II


◆ The opcodes should be valid, and for every opcode, the correct values and

types should be stored in the local variables in the frame and in the operand stack. Therefore, the bytecode verifier performs these checks on a set of bytecodes and decides whether it is safe for JVM to execute these bytecodes. These checks revolve around the set of rules specified in the Java programming language. Depending on the nature of the constraints, the bytecodes compiled by a Java program would pass the bytecode verifier checks. However, the bytecodes that are not generated by the Java compiler may also pass the bytecode verifier checks with flying colors. Therefore, the bytecode verifier is not completely foolproof. The process of a bytecode verifier is illustrated in Figure 5-4.

FIGURE 5-4 The role of bytecode verifier


Chapter 5

Pass Four: Symbolic Reference Check The last pass occurs during the dynamic linking process in which the symbolic references contained in a class file are resolved. In this pass, the classes referenced by the class file are verified; therefore, as these classes are external to the specified class file, they need to be loaded. However, these classes are loaded only when they are actually needed in the program. If a referenced class is not found by JVM, it does not raise the NoClassDefFoundError exception unless the class is actually used for the first time in an executing program. The linking depends upon the JVM implementation. If JVM performs early linking, pass four occurs immediately after pass three. On the other hand, if the JVM implementation resolves symbolic references only when they occur for the first time in the program, pass four occurs well after pass three, when the execution of the bytecodes begins. Pass four is a part of dynamic linking, which resolves the symbolic references in a specified class. A class might contain symbolic references to other classes via the fields and methods defined in the specified class.

NOTE A symbolic reference is a string that contains information that uniquely identifies the referenced field or method of a class. For example, a symbolic reference to a field contains the class name, field name, and field descriptor. On the other hand, a symbolic reference to a method contains the class name, method name, and method descriptor.

While executing bytecodes, when JVM comes across a symbolic reference to another class for the first time in an opcode, it attempts to resolve the symbolic reference. First, JVM locates and loads the referenced class. It then replaces the symbolic reference with a direct reference to the specified class. This direct reference can be an offset to the specified field or method of the referenced class. JVM needs to resolve a symbolic reference only the first time it encounters the reference in the program. The next time JVM encounters the reference, it only needs to access the specified field or method by using the direct reference. When JVM resolves a symbolic reference, it is the task of the class file verifier to check whether the given reference is valid. The validity is checked in terms of whether the class can be loaded and if the specified class contains the referenced field or method. If either of these conditions is false, the class file verifier throws an error. Let’s consider an example to explain the previous concept. Assume that your Java program has a class, House. The method of this class, openDoor(), invokes a method in the class, Door. The binary data contained in the class file for House includes the name

115

116

Part II


and descriptor of the method in Door. When the method in the class, House, invokes the method in class Door, the class file verifier checks that the method in the class, Door, matches the specifications listed in the House class file. If the symbolic reference is valid, the class file verifier substitutes this reference with a direct reference such as a pointer to the specified method. However, if the reference is not valid, JVM throws a NoSuchMethodError.

Checking for Binary Compatibility You are already aware that Java programs are dynamically linked. This is the main reason why pass four of the Java compiler needs to check the class references for compatibility issues. Usually, the Java compilers recompile the classes that depend on a recently changed class. Therefore, any incompatibility issues are traced at compile time itself. However, at times, the compiler does not recompile the dependent classes. For example, when you are designing large systems where various parts of the system are split into packages, you may ignore the class linking across the various packages. Therefore, pass four of the class file verifier needs to check for binary compatibility.

Data Flow Analyzers Even after the bytecode is checked for syntax errors and binary compatibility, the task of the bytecode verifier is not complete. The bytecode verifier needs to analyze the runtime behavior of the bytecode. To perform this analysis, the bytecode verifier needs to know the status of the stack for each instruction before executing it. The number and type of items in the stack is checked. The type of local variables is also checked before executing a specific instruction. The analysis of the runtime behavior of bytecode is performed by the data flow analyzer, which needs to be initialized. The initialization phase marks each instruction as unvisited, indicating that the data flow analyzer has not yet examined the specified instruction. Then, the stack is emptied for the first instruction and the local variables are initialized according to the appropriate types. The local variables that are considered as used by the method, are declared to be containing illegal values. Finally, in the initialization phase of the data flow analyzer, the changed bit of the first instruction is set. This indicates that the analyzer needs to examine the instruction. After the data flow analyzer is initialized, it performs the following tasks. First, it checks for a JVM instruction whose changed bit is set. If it is unable to locate any such instruction, this indicates that the specified method has been successfully verified. On the other hand, if it locates such an instruction, it turns off the changed bit and imitates the effect of the instruction on the stack and the local variables. The data flow analyzer checks whether the specified instruction uses values from the stack. It checks whether the elements on top of the stack are in the correct numbers and types. If the specified


Chapter 5

instruction pushes some values on the stack, the analyzer needs to check whether there is sufficient space in the stack and needs to update the stack status to reflect the pushed values. If the specified instruction reads a local variable, the analyzer needs to check whether the specified variable contains a value of the appropriate type. The analyzer also needs to change the type of the specified variable if a value is written to it. Then, the analyzer needs to determine which instructions will possibly be executed next. This can be the first instruction of the exception handlers for the specified instruction or the target instruction of a conditional or unconditional branch. In case the current instruction is not an unconditional goto or return, the next instruction in the sequence is considered. Finally, the analyzer merges the state of the stack and the local variables after executing the current instruction with the state prior to executing the current instruction. An error can be traced if the stacks are of different sizes. All these steps are executed repeatedly until the entire method has been analyzed and no JVM instruction has its changed bit set.

Summary In this chapter, I discussed the basics of class loaders. I also discussed the types of class loaders and the core architecture of class loaders. Next, I discussed the parent-delegation model in detail. The working of class loaders and the version changes across jdk1.1 and jdk1.2 for class loader implementation were also discussed. Then, I discussed the function of the class file verifier in detail. Finally, I discussed the four passes of the class file verifier process.

Check Your Understanding Multiple Choice Questions 1. Which of the following allows classes to be loaded from the directories specified in the java.app.class.path property? a. Applet class loaders

c. RMI class loaders

b. Secure class loaders

d. URL class loaders

2. The class, java.net.URLClassLoader, is a subclass of which of the following classes? a. SecureClassLoader

c. AppletClassLoader

b. ClassLoader

d. SecurityManager

117

118

Part II


3. Which of the following is the function of the loadClass() method? a. Defining a namespace containing a set of class names, which includes the name of the class loaded and the classes referenced by this class. b. Loading referenced classes. c. Checking whether a class needs to be loaded. d. Searches the class path. 4. In jdk1.2, the custom class loaders override which of the following methods? a. loadClass()

c. defineClass()

b. findClass()

d. findSystemClass()

5. In which of the following passes does the class file verifier check the integrity of the bytecodes contained in the class file? a. Pass one

c. Pass three

b. Pass two

d. Pass four

Short Questions 1. Explain the parent delegation model. 2. Explain the function of pass three of the class file verifier. 3. Explain the role of data flow analyzers.

Answers Multiple Choice Answers 1. b. The secure class loader allows classes to be loaded from the directories specified in the java.app.class.path property. 2. a. The class, java.net.URLClassLoader, is a subclass of the SecureClassLoader class. 3. a, b, and c. It is the task of the class loader to create a namespace containing a set of class names, which includes the name of the class loaded and the classes referenced by this class. The class loader performs this function using the loadClass() method, whose definition is as follows. loadClass(String className, boolean resolveIt);

The className string represents the class to be loaded by the class loader. The resolveIt variable indicates whether a referenced class needs to be loaded. The code for a class loader searches the class path and the Zip files for loading classes.


Chapter 5

4. b. In jdk1.2, the custom class loaders do not override the loadClass() method; instead, they override the findClass() method, which contains the custom class loading logic. 5. b and c. In passes two and three, the class file verifier checks the integrity of the bytecodes contained in the class file and checks the types against the rules and semantics of the Java programming language.

Short Answers 1. In jdk1.2, there is a new parent-delegation model for class loaders. The class loaders created in the earlier versions of Java still work in jdk1.2; however, they do not take advantage of the parent-delegation model. When you create a user-defined class loader in jdk1.2, each such loader has a parent class loader associated with it. If a parent class loader is not passed explicitly to the constructor of the user-defined class loader, the system class loader takes on the role of the parent. When a new user-defined class loader is created, the parent loader is passed to the constructor. On the other hand, if an existing userdefined class loader is passed to the constructor of a new user-defined class loader, this user-defined class loader becomes the parent of the new loader. 2. In pass three, the class file verifier checks the bytecodes contained in class files. In this pass, the class file verifier is called the bytecode verifier instead. JVM performs a data check on the bytecodes that represent the methods of a specified class. The Java methods are represented as bytecode streams that consist of many 1-byte instructions called opcodes. These opcodes are followed by one or more operands, which provide additional data to JVM to execute a specified opcode instruction. Bytecodes represent a thread of execution in JVM, and each such thread has a stack, which contains frames. When a method is invoked, the specified bytecode gets its own frame, which is a memory area where the method can store information such as parameters or the result of an intermediate computation. An operand stack is that part of the frame that contains the result of an intermediate computation. Therefore, when JVM executes an opcode, it may need to constantly refer to the operand stack or the method frame that contains the parameters and local variables. There are many checks performed by a bytecode verifier before executing a stream of bytecodes in JVM. A few of these checks are as follows: • Irrespective of the way in which an opcode is executed, the operand stack should always contain the same number and type of items. • No local variable should be accessed before it is assigned a proper value. • The class members, namely the fields and methods, should contain proper values. The class fields should always be assigned values of the correct data

119

120

Part II


types. The class methods should be invoked with the correct number and type of parameters. • The opcodes should be valid, and for every opcode, the correct values and types should be stored in the local variables in the frame and in the operand stack. 3. The analysis of the runtime behavior of bytecode is performed by the data flow analyzer, which needs to be initialized. The initialization phase marks each instruction as unvisited, indicating that the data flow analyzer has not yet examined the specified instruction. Then, the stack is emptied for the first instruction and the local variables are initialized according to the appropriate types. The local variables that are considered as used by the method are declared to be containing illegal values. Finally, in the initialization phase of the data flow analyzer, the changed bit of the first instruction is set. This indicates that the analyzer needs to examine the instruction. After the data flow analyzer is initialized, it performs the following tasks. First, it checks for a JVM instruction whose changed bit is set. If it is unable to locate any such instruction, this indicates that the specified method has been successfully verified. On the other hand, if it locates such an instruction, it turns off the changed bit and imitates the effect of the instruction on the stack and the local variables. The data flow analyzer checks whether the specified instruction uses values from the stack. It checks whether the elements on top of the stack are in the correct numbers and types. If the specified instruction pushes some values on the stack, the analyzer needs to check whether there is sufficient space in the stack and needs to update the stack status to reflect the pushed values. If the specified instruction reads a local variable, the analyzer needs to check whether the specified variable contains a value of the appropriate type. The analyzer also needs to change the type of the specified variable if a value is written to it. Then, the analyzer needs to determine which instructions will possibly be executed next. This can be the first instruction of the exception handlers for the specified instruction or the target instruction of a conditional or unconditional branch. In case the current instruction is not an unconditional goto or return, the next instruction in the sequence is considered. Finally, the analyzer merges the state of the stack and the local variables after executing the current instruction with the state prior to executing the current instruction. An error can be traced if the stacks are of different sizes. All these steps are executed repeatedly until the entire method has been analyzed and no JVM instruction has its changed bit set.

Chapter 6 Java 2 Security Manager

I

n the previous chapter, I discussed the role of the class loader and class file verifier in the security implementation of Java. However, this implementation is incomplete without a security manager. You are already aware of the security invasions on a Java system. These can vary from system modification, whereby a program can modify the system by acquiring false permissions, to system impersonation, whereby a malicious program poses as a real program and gains access to all valuable system resources. The Java security manager can be used to eliminate these security threats. The security manager enforces restrictions based on permissions specified in policy statements. The three core elements of JVM that implement security—the class loader, class file verifier, and security manager—are interdependent. The security manager depends on the class loader for the following tasks: ◆ Loading both trusted and untrusted classes ◆ Keeping both untrusted and local classes in different namespaces ◆ Applying different protection domains to these classes ◆ Preventing local trusted classes from being overwritten by untrusted classes

The class loader also depends on the security manager to prevent a malicious applet from loading its own class loader. Finally, both of these depend on the class file verifier to ensure that the contents of the class file are syntactically correct and that there is no deviant bytecode in them. In this chapter, I’ll discuss the role of security manager and how it implements security in the system in detail.

The SecurityManager Class The java.lang.SecurityManager class has been present since jdk1.0 and its behavior has been simpler than that of the class in Java 2. The SecurityManager class contains many methods preceded with the check keyword. Each of these methods corresponds to a potentially harmful operation of any Java program. For example, the checkRead() method is called when the program is supposed to read from a specified file. If the check proceeds normally, the program will proceed with the read

JAVA 2 SECURITY MANAGER

Chapter 6

operation, otherwise the method throws a SecurityException. The check methods are typically invoked as follows: SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkRead(argument, ….); }

However, this check takes place only when the security manager is active. By default, Java applications run without any security manager. Therefore, all the operations are allowed. You can specify the security manager for your Java application by the following two methods. ◆ Specify a command-line option ◆ Activate the security manager in your application code

You can set the default security manager for your application by using the -Djava.security.manager option on the command line. The default security man-

ager imposes restrictions similar to those placed on applets, thereby preventing most of the sensitive operations from being performed. For example, if you wish to set the default security manager for your Java application, myWebApp, you use the following command. java -Djava.security.manager myWebApp

In the second method, you can activate the security manager in your application code by using the setSecurityManager() method of the System class. Consider the following code snippet: public static void main(String[] args) { SecurityManager myManager = new SecurityManager(); System.setSecurityManager(myManager)

In this example, an instance of the default SecurityManager class is created. However, a subclass of the SecurityManager class can also be used. In earlier versions of Java, customizing the SecurityManager class was very easy. All you had to do was create a subclass from the default SecurityManager class. However, there were certain problems associated with this: ◆ You had to change the Java source code to implement new security policies

because the security rules were specified in the source code. ◆ To add a custom permission, you had to define a new method in your SecurityManager subclass. This was inappropriate because this subclass already

contained inherited methods from its superclass.

123

124

Part II


The Java 2 security model solves these problems by storing the permissions separately so that you don’t have to modify the source code. In Java 2, the SecurityManager class still contains the check methods that are called when a potentially harmful operation needs to be performed. However, in Java 2, the default implementation of these methods is to call the checkPermission method, which, in turn, checks whether the calling thread has the permissions to perform the specified operation. The checkPermission method is defined in the AccessController class, which is defined in the java.security package. The AccessController class refers to the policy file to decide whether a particular operation is assigned the specific permission. You’ll read more about the AccessController class and permissions in Chapter 7, “The Access Controller and Permissions in Java 2”. Now I’ll discuss the SecurityManager class and its important components. I’ll discuss the various check methods based on the type of unsafe operation on which the security manager is concentrating. For example, the security manager has different check methods for checking network operations and file system operations.

Network Operations Checks The various check methods for network operations along with their functionality are listed here: ◆ checkAccept: This method throws a SecurityException if there is no per-

mission specified in the policy file. This permission allows the calling thread to accept a socket connection from the specified host and port number. The method definition is specified as follows: public void checkAccept(String host, int port)

This method is invoked for the security manager when an instance of the ServerSocket class calls its accept() method. The checkPermission method is called with the SocketPermission as its parameter. ◆ checkConnect: This method checks whether the calling thread is allowed to

open a socket connection with the specified host and port number. The method definition is specified as follows: public void checkConnect(String host, int port)

You are already aware of the fact that the check methods call the checkPermission method and pass the specified permission as a parameter. The checkConnect method calls the checkPermission method with the SocketPermission(host+”:”+port,”connect”) or SocketPermission(host,”resolve”) method as its parameter.


Chapter 6

◆ checkListen: This method checks whether the calling thread can wait for a

specified connection request on the given local port. The method definition is specified as follows: public void checkListen(int port)

If the port is 0, this method calls the checkPermission method through the SocketPermission(“localhost:1024-”,”listen”) method. On the other hand, if the port is not 0, this method calls checkPermission with the SocketPermission(“localhost:”+port,”listen”) method. ◆ checkMulticast: This method throws a SecurityException if the calling

thread is not allowed to use IP multicast. The method definition is specified as follows: public void checkMulticast(InetAddress maddr)

This method calls the checkPermission method with the SocketPermission(maddr.getHostAddress(), “accept,connect”) method as its parameter. ◆ checkSetFactory: This method checks whether the calling thread is allowed to set the socket factory used by the ServerSocket or Socket class. The

method definition is specified as follows: public void checkSetFactory()

The checkPermission method is called by passing the RuntimePermission(“setFactory”) permission.

File System Checks The various file system check methods are listed here: ◆ checkDelete: This method checks whether the specified thread is supposed to delete a file. This method is invoked when a class File object tries to delete a file through its delete method. The method definition is specified

as follows: public void checkDelete(String file)

The checkPermission method is called with the FilePermission(file,”delete”) permission as its parameter. ◆ checkRead: This method checks whether the specified thread is supposed to

read a file. The method definition is specified as follows: public void checkRead(String file)

125

126

Part II


The checkPermission method is called with the FilePermission(file,”read”) permission as its parameter. ◆ checkWrite: This method checks whether the specified thread is supposed

to write to a file. The method definition is specified as follows: public void checkWrite(String file)

The checkPermission method is called with the FilePermission(file,”write”) permission as its parameter.

Thread Checks There is a single thread check method called checkAccess(). The security manager invokes this method when the calling thread is not allowed to modify thread arguments. This method is invoked when an object of the Thread class calls its setDaemon, setPriority, setName, stop, suspend, and resume methods. The method definition is specified as follows: public void checkAccess(Thread myThread)

This method operates depending on whether the thread argument is a system thread. If the thread argument is a system thread, this method calls the checkPermission method with the RuntimePermission(“modifyThread”) permission as its parameter. On the other hand, if the thread argument is not a system thread, the method returns back normally. However, for applications that want more access restrictions, the policy file might need to override this method. The resulting method needs to check whether the calling thread has the RuntimePermission(“modifyThread”) permission. If this permission is specified, the method returns back. This ensures that the code granted the RuntimePermission(“modifyThread”) permission is allowed to modify any thread.

Package and Class Access Checks There are certain check methods in the SecurityManager class for avoiding dangerous operations to be performed on packages and classes. These check methods are listed here: ◆ checkPackageAccess: This method checks whether the calling thread has

permissions to access a specified package. This method is typically used by the loadClass method of class loaders. The method definition is specified as follows: public void checkPackageAccess(String myPackage)


Chapter 6

This method first acquires a list of restricted packages by accessing java.security.Security.getProperty(“package.access”). It then compares the myPackage parameter with this list to check whether the package name either starts with or is same as the name of a restricted package. If the parameter is not similar to a restricted package, the checkPermission method is called with the RuntimePermission(“accessClassInPackage.”+myPackage) permission. ◆ checPackageDefinition: This method checks whether the calling thread

can define classes in the specified package. This method is typically used by the loadClass method of class loaders. The method definition is specified as follows: public void checkPackageDefinition(String myPackage)

This method works in a similar fashion as the checkPackageAccess method. It first looks for the list of restricted packages and checks if myPackage starts with or is same as a restricted package. If the parameter is not similar to a restricted package, the checkPermission method is called with the RuntimePermission(“defineClassInPackage.”+myPackage) permission. ◆ checkMemberAccess: This method checks whether the calling thread is

allowed to access the members of a specified class. The method definition is specified as follows: public void checkMemberAccess(Class myClass, int a)

Based on the default policy file, access is allowed to the public members of the class. On the other hand, access is also allowed to classes that have the same class loader as the calling class. If both these conditions are not true, this method calls the checkPermission method with the RuntimePermission(“accessDeclaredMembers”) permission as its parameter.

Operating System Checks The security manager also checks the access to operating system resources during the execution of a Java program. This helps in restricting malicious Java code from tampering with operating system resources, which can lead to system crash. The check methods for controlling access to operating system resources are listed here: ◆ checkExec: This method checks whether the calling thread is allowed to

create a subprocess. The security manager invokes this method when an object of the class Runtime calls its exec method. The method definition is specified as follows: public void checkExec(String cmd)

127

128

Part II


The cmd parameter specifies the system command to be executed. This method invokes the checkPermission method with the FilePermission(cmd,”execute”) permission as its parameter. ◆ checkPrintJobAccess: This method checks whether the calling thread is

allowed to initiate a print job request. The method definition is specified as follows: public void checkPrintJobAccess()

This method, in turn, invokes the checkPermission method with the RuntimePermission(“queuePrintJob”) permission as its parameter. ◆ checkSystemClipboardAccess: This method checks whether the calling

thread is allowed to access the system Clipboard. The method definition is specified as follows: public void checkSystemClipboardAccess()

This method, in turn, invokes the checkPermission method with the AWTPermission(“accessClipboard”) permission as its parameter. ◆ checkLink: This method checks whether the calling thread is allowed to

dynamically link the specified library code. The method definition is specified as follows: public void checkLink(String lib)

The string parameter passed to this method is either a library name or a complete file name. The security manager invokes this method when an object of the class Runtime calls its load and loadLibrary methods. This method invokes the checkPermission method with the RuntimePermission(“loadLibrary.”+lib) permission as its parameter.

JVM Control To avoid the risk of any malicious code trying to crash JVM, the security manager has certain check methods. These methods control the access to various components and members of JVM. The various check methods for JVM control are listed here: ◆ checkExit: This method checks whether the calling thread is allowed to

cause JVM to halt based on the specified status. The security manager invokes this method when an object of the class Runtime calls its exit method. The method definition is specified as follows: public void checkExit(int status)

If the status parameter contains 0, it indicates that the exit is successful. Any other value indicates failure of the exit operation. This method, in turn,


Chapter 6

invokes the checkPermission method with the RuntimePermission(“exitVM”) permission as its parameter. ◆ checkPropertyAccess: This method checks whether the calling method is

allowed to access the system property with the specified key name. This method is used when an object of the class System calls its getProperty method. The method definition is specified as follows: public void checkPropertyAccess(String key)

The key parameter is a system property key. This method invokes the checkPermission method with the PropertyPermission(key, “read”) permission as its parameter. ◆ checkPropertiesAccess: This method checks whether the calling thread is

allowed to access or modify system properties. This method is invoked when an object of the System class calls its getProperties and setProperties methods. The method definition is specified as follows: public void checkPropertiesAccess()

This method invokes the checkPermission method with the PropertyPermission(“*”, “read,write”) permission as its parameter. ◆ checkAwtEventQueueAccess: This method checks whether the calling

method is allowed to access the AWT event queue. The method definition is specified as follows: public void checkAwtEventQueueAccess()

This method invokes the checkPermission method with the AWTPermission(“accessEventQueue”) permission as its parameter. ◆ checkCreateClassLoader: This method checks whether the calling thread is

allowed to create a new class loader. The method definition is specified as follows: public void checkCreateClassLoader()

This method invokes the checkPermission method with the RuntimePermission(“createClassLoader”) permission as its parameter.

Security Functions The security manager also checks whether a specified security function can be executed or not. The security manager has a single method, checkSecurityAccess, for controlling security functions. The method definition is specified as follows: public void checkSecurityAccess(String target)

129

130

Part II


This method checks whether the permission with the specified permission target name should be granted or denied. If the specified permission is granted, the method returns back; otherwise a SecurityException is raised. This method creates a SecurityPermission object for the specified permission contained in the target parameter. This object in turn invokes the checkPermission method. Now that I have discussed the SecurityManager class in detail, I’ll discuss how the security manager helps in implementing security.

How the Security Manager Works The source code consults the security manager whenever an unsafe operation is performed in JVM. The security manager considers the location of the code before taking its decisions. For example, the Java API core classes are given more freedom as compared to the classes downloaded from the Web. In other words, classes from a trusted source are not limited by major security restrictions as in the case of classes loaded from an untrusted source. The flow of operation of the security manager is as follows: ◆ A Java program makes a call to a potentially unsafe operation. ◆ The Java API code checks with the SecurityManager class whether this

unsafe operation is allowed in the system. ◆ The SecurityManager class returns a security exception if the operation is

not possible. This exception is returned to the specified Java program. ◆ If the SecurityManager class approves of the operation, it returns normally

and the Java program proceeds with the execution of the dangerous operation. Every JVM can have a single security manager installed at a time. A security manager cannot be uninstalled, except by restarting JVM. However, the active security manager can be replaced if the current program can either create an instance of the SecurityManager class or set a given instance as active. Therefore, the respective permission needs to be specified in the policy file for this class. Consider the following code statements: grant codeBase “file:/C:/myWeb” { permission java.lang.RuntimePermission “createSecurityManager”; permission java.lang.RuntimePermission “setSecurityManager”; };


Chapter 6

The previous code statements allow any application in the C:/myWeb directory to replace the active security manager. Therefore, the security manager checks whether the specified instructions have permissions to perform an operation. For example, suppose an instruction in your program needs to connect to a specified host through a given port. Now, the security manager needs to check whether the specified instruction has the permission to perform this operation. It does this through the checkConnect(host, port) method. If the java.net.SocketPermission is specified in the policy file, the program proceeds normally. Otherwise, a SecurityException is raised. Java-enabled applications, such as Web browsers, install a security manager during their initialization phase. This step protects the system before any malicious code is executed. The security exception raised by the security manager travels through all the methods of the thread that made the call to the potentially dangerous operation. When it reaches the topmost method, the specified thread is terminated. When considering security, you should not count just on exceptions to avoid dangerous operations from being performed by hostile applets. This is because it is possible for these hostile applets to catch the security exceptions generated by a try…finally block. The SecurityManager class can be customized through subclassing. However, applets cannot install their own security managers because this would open all doors for malicious applets. The security manager performs certain tasks that prevent untrusted applets from attacking the system or JVM. These tasks involve: ◆ Controlling the ability to exit JVM ◆ Preventing file system activities such as read and write ◆ Controlling network socket operations such as accept and connect

These tasks are performed by using the various check methods discussed in the preceding section. Figure 6-1 depicts the security manager operation. You have read in the preceding section that the security manager controls both the operating system and JVM resources. However, a program needs certain system or network resources to successfully complete its execution. These resources need to be controlled if the program has been downloaded from a remote site. I’ll now discuss the various types of attacks from malicious applets that are beyond the reach of the security manager.

Areas Not Controlled by the Security Manager A malicious applet can cause different types of attacks on a system. One of the most common categories of attacks is denial of service attacks. They are so called because they deny users the ability to use their own computers. These attacks can be posed as different types ranging from consuming available CPU cycles, using up all memory

131

132

Part II


FIGURE 6-1 Security manager operation

space, or causing a system to hang. These attacks suffer the same consequence of restricting users from using their computers. Cases where applets can typically initiate these attacks are listed here: ◆ A malicious applet starts a thread with MAX_PRIORITY that competes with

the currently running threads for CPU time. ◆ A cracker can define the thread’s stop() method to null. ◆ A malicious applet involves the thread in some intensive calculations, which

eats up most of the CPU time. ◆ A malicious applet can create an infinite number of windows that would use

up both CPU time and memory. Denial of service attacks are less serious than the remaining security risks that attack the system directly. These attacks may pose a risk to the browser because they may crash it. However, they cannot tamper with a system. Therefore, many people ignore these attacks. However, it is advisable not to ignore these attacks. These can be con-


Chapter 6

trolled by restricting resource access, namely limiting CPU usage or restricting the number of instructions that can be run in a single program. The different types of these attacks are covered in the next few sections.

Opening Large Number of Oversized Windows Opening a large number of oversized windows might prove to be a much more serious attack as compared to the denial of service attacks. These windows render the keyboard and mouse useless when they pop up on the screen. When multiple windows are being created, few untrusted windows might pop up without any warning. These multiple windows cause the window manager’s event queue to be filled up. This disables the keyboard and mouse, which also use window events to interact with the computer. Crackers can use these windows to solve their malicious purposes. For example, imagine a cracker writes code that generates an imitation of a password window. Users unknowingly enter their user ID and password, which are captured by a malicious applet and sent to the cracker’s site, where they are stored for future use. Therefore, a user can be easily fooled through such attacks. This example shows how an attack can be posed through the loopholes in the security model.

Cycle Stealing Cycle stealing refers to any program that consumes resources without the user’s permission. There are certain difficult computational problems, which can scale exponentially. These problems could exhaust all the CPU time and memory space by stealing CPU cycles from other executing programs. Imagine a Web page containing a malicious applet that contains such code. This applet could steal cycles from the computer of any user who accesses this Web page. The applet could start a thread on the computer containing the Web page and execute the factoring or complex calculation on that computer’s CPU who has accessed the specified Web page. An applet can perform any complicated task to steal cycles from the user’s computer. This task is not limited just to computational areas. Using a malicious applet, crackers can upgrade their computers by using the combined CPU power of multiple workstations on a network.

Forging E-Mails Another attack to the system is that of forging e-mails. This can be done by talking directly to the SMTP daemon on a server’s port 25. Such an attack is possible because mail hosts use port 25 for incoming Simple Mail Transfer Protocol (SMTP) messages. Applets can also be used in forging e-mails because they are loaded across the network. Therefore, a mail-forging applet does not cause an SMTP daemon on port

133

134

Part II


25 to report mail coming from the computer serving the applet. Instead, the daemon reports mail coming from the Web surfer’s computer. Therefore, this can doubly forge mail. For example, imagine that you visit a Web page where a malicious applet is run. This applet uses your computer and your account on that computer to doubly forge mail. Moreover, when this mail reaches the receiving end it does not appear to be forged at all. Therefore, forged mail can be sent to any e-mail address. By using threads and applets, a cracker can easily forge mail in the background while a user is accessing an applet unknowingly at the front. The entire process of forging mail could be understood through Figure 6-2. However, the preceding scenario does not fall under the category “Areas not controlled by a security manager” in the real sense. An untrusted applet is not allowed to connect to any other computers. Therefore, there is no question of mail forging. The security manager can control mail forging by not trusting arbitrary applets to begin with. It is purely at the discretion of the applet to breach the trust that is granted. In such cases, it is a breach of trust and not a breach of security. The attacks discussed previously are generally introduced in the system through public methods defined in a given class. Therefore, a method should be defined public only after some thought. Instead define it as protected or private. This may close the potential security holes in the system. When these changes have been made, you’ll need to check whether the applet’s functionality has been affected.

FIGURE 6-2 The mail-forging approach


Chapter 6

The security manager does not enforce any restrictions on these attacks, which either allocates memory or leads to thread creation. In other words, there are no checkAllocateMemory() or checkCreateThread() methods in the SecurityManager class that can control these events. Therefore, a security manager alone cannot prevent every risky operation on your computer. You are already aware that besides these attacks, the security manager provides check methods for every other potentially unsafe operation.

Writing Your Customized Security Manager From the preceding sections, you can gather that the security manager is a JVM object that can implement a security policy through the various methods defined in its class. By default, the security manager does not permit access to local system resources except for read and write permissions for the directory and subdirectories from where a specified Java program is invoked. However, you can customize the default security manager so that it can implement customized checks for your applets and applications. Note that this customized security manager must contain access verification code for every check method that you override. I’ll discuss an application that uses a customized security manager. This application prompts users for password information before they can access threads on the system. The customized security manager also looks into the fact that even though users have cleared the password check, they would still need the specific permissions in the policy file for them to access a specified thread. I’ll write a customized security manager that prompts the user for a password before allowing a specified program to access a thread. The SecurePasswordManager class contains the customized security manager implementation. Let’s discuss this class in detail. The SecurePasswordManager class has two private instance variables to contain the password string and an input buffer, which stores the user’s password input. Therefore, the SecurePasswordManager class definition is specified in the following code: public class SecurePasswordManager extends SecurityManager{ private String password; private BufferedReader myBuffReader; public SecurePasswordManager(String myPass, BufferedReader br){ super(); this.password = myPass;

135

136

Part II


this.myBuffReader = br; } private boolean verifyAccess(){ int a; String mySecretPassword; System.out.println(“Enter your password:”); try{ mySecretPassword = myBuffReader.readLine(); if (mySecretPassword.equals(password)) return true; else return false; } catch (IOException e){ return false; } } }

Finally, at the end of the SecurePasswordManager class, you can define two overridden checkAccess() methods. The code listing for these follows: public void checkAccess(Thread a){

if(!verifyAccess()) throw new SecurityException (“No access available”); } public void checkAccess(ThreadGroup a){

if(!verifyAccess()) throw new SecurityException (“No access available”); }

Both the methods defined in the previous code call the verifyAccess() method, which prompts the user for a password. If the access does not contain a true value, the methods throw a SecurityException; otherwise the methods return back normally. Another aspect to be noted about these checkAccess() methods is that they cannot independently determine that a restricted thread access is being performed. The checkAccess() methods determine whether to allow access to the current thread or the thread or thread group passed as parameters to them.


Chapter 6

You can override multiple check methods to implement your customized security policy. You need not override all the check methods of the SecurityManager class. Override only those that you need to customize. However, all the check methods operate in a similar fashion. If the specified access is allowed, they return normally; otherwise they raise a SecurityException. The previous example proves that creating your own security manager is not difficult. All you have to do is create a SecurityManager subclass and override the methods that you need to customize. Which methods should you override? The answer to this question is simple. I have already segregated the check methods based on their operations in a preceding section. All you have to decide is the area on which you are performing the customized operation. For example, you are trying to customize the policy for access permissions on files, which restrict a user to read or write to a specific file. In such a case, you will override the check methods defined for the file system, namely checkDelete(), checkWrite(), and checkRead(). However, while overriding the various check methods, you need to consider all the situations in which the specific method can be invoked. You are already aware that you need to explicitly call the security manager for security checks in the system. Therefore, the specified program will declare the custom security manager in its main method. The code listing for this main method follows: public static void main(String[] args) { BufferedReader myBuffReader = new BufferedReader (new InputStreamReader(System.in)); try { System.setSecurityManager(new SecurePasswordManager (“password”, myBuffReader)); } catch(SecurityException e) { System.out.println(“Cannot replace the existing security manager!!!”); } }

Therefore, the following code statement creates a new instance of the SecurePasswordManager class with the password “password”. This instance is passed to the System.setSecurityManager() method, which installs this instance as the security manager for the running application. System.setSecurityManager(new SecurePasswordManager(“password”, myBuffReader));

137

138

Part II


However, the life of this security manager is limited until the program is running. Only one instance of security manager is allowed for a running program. If the running application tries to create another instance, a SecurityException is raised. The main() method also contains a test application that creates a thread group and few threads within it. Finally, the test application starts all the threads. This application should contain instances of restricted thread access for the method to invoke the customized security manager. Consider the following code: Thread myThread[] = new Thread[3]; ThreadGroup myGroup = new ThreadGroup(“ Many Threads”); for (int i = 0; i < 3; i++) { myThread[i] = new Thread(myGroup, String.valueOf(i)); myThread[i].start(); }

The code statements defined in the for loop are restricted thread statements because they are trying to access threads. These statements will invoke the SecurePasswordManager checkAccess() methods, which, in turn, will invoke the verifyAccess() method. Finally, you’ll run the application with the specified main() method to test the security manager. You’ll be prompted to enter the password every time a thread or thread group is created or accessed. If you enter the correct password, access is granted, whereas if you enter the wrong password, the checkAccess() method throws an exception. Refer to Figure 6-3 for an example.

FIGURE 6-3 The exception raised in the TestApp program upon entering

the wrong password


Chapter 6

Let’s consider another example where the read and write access to a file is controlled through a custom security manager. Therefore, when you try to read or write a specified file, you are prompted for a password. If the user enters the correct password, the file access permissions in the policy file are checked. Only after these permissions have been checked will you be able to perform read and write operations in the specified files. Therefore, the custom security manager class for this application would be similar to the one discussed previously. The only difference would be the check methods that need to be overridden. In the earlier example the check methods for threads, namely checkAccess(Thread a) and checkAccess(ThreadGroup a), were overridden. In this example, the checkread() and checkwrite() methods need to be overridden. Consider the code for this example. public class SecurePasswordManager extends SecurityManager{ private String password; private BufferedReader myBuffReader; public SecurePasswordManager(String myPass, BufferedReader br){ super(); this.password = myPass; this.myBuffReader = br; } private boolean verifyAccess(){ int a; String mySecretPassword; System.out.println(“Enter your password:”); try{ mySecretPassword = myBuffReader.readLine(); if (mySecretPassword.equals(password)) return true; else return false; } catch (IOException e){ return false; } } public void checkRead(String myFile) { if((myFile.equals(File.separatorChar + “C:” + File.separatorChar + “myDir” +

139

140

Part II


File.separatorChar + “readFile.txt”))){ if(!verifyAccess()){ super.checkRead(myFile); } else { FilePermission myPerm = new FilePermission( File.separatorChar + “C:” + File.separatorChar + “myDir” + File.separatorChar + “ readFile.txt”, “read”); checkPermission(myPerm); } } }

public void checkWrite(String myFile) { if((myFile.equals(File.separatorChar + “C:” + File.separatorChar + “myDir” + File.separatorChar + “writeFile.txt”))){ if(!verifyAccess()){ super.checkWrite(myFile); } else { FilePermission myPerm = new FilePermission( File.separatorChar + “C:” + File.separatorChar + “myDir” + File.separatorChar + “writeFile.txt” , “write”); checkPermission(myPerm); } } } }

The checkRead() and checkWrite() methods are overridden as shown in the bold code. The checkRead method first checks for the path /C:/myDir/readFile.txt. If the path exists, the user is prompted for the password twice. First, when the user tries to read the C:/myDir directory and second, when the user attempts to read the readFile.txt file. If the password supplied by the user is correct, the checkRead method performs the access check by calling the checkPermission method. An instance of the FilePermission class is passed as its parameter to the checkPermission method. This parameter checks whether the specified file has read permissions.


Chapter 6

The permissions are specified in the policy file. The checkWrite method operates similarly as the checkRead method. The policy file should have the following entries for a user to successfully read and write to the specified files. grant { permission java.io.FilePermission “C:/myDir/writeFile.txt”, “write”; permission java.util.PropertyPermission “C:/myDir”, “read”; permission java.io.FilePermission “C:/myDir/readFile.txt”, “read”; };

These examples show that to write a custom security manager, you need to create a SecurityManager subclass and override the methods that you need to customize.

Summary In this chapter, I discussed the interdependence of the three security components of JVM namely, class loader, class file verifier, and security manager. I discussed the SecurityManager class in detail. In addition, I discussed all the check methods for the SecurityManager class according to the area controlled by them. Next, I focused on how the security manager is invoked in a Java application. The security manager cannot control certain areas. These areas pose the problem of security threats. This was also discussed in this chapter. Finally, I discussed how you can customize the SecurityManager class to limit resources based on your requirements.

Check Your Understanding Multiple Choice Questions 1. Which of the following statements is true? a. By default, Java applications run without any security manager. b. By default, Java applications run with a security manager. c. If the check does not proceed normally, the method throws a SecurityException. d. The SecurityManager class contains many methods preceded with the check keyword.

141

142

Part II


2. Which of the following methods is used to specify the security manager for your Java application? a. Specify a command-line option. b. Use the -Djava.security.manager option. c. Invoke the check methods. d. Activate the security manager in your application code. 3. Which of the following methods are used to check network operations? a. checkConnect() b. checkListen() c. checkSetFactory() d. checkSecurityAccess() 4. What is the function of the checkPropertiesAccess() method? a. This method determines whether the calling method is allowed to access the system property with the specified key name. b. This method determines whether the calling thread is allowed to access the members of a specified class. c. This method determines whether the calling thread is allowed to access or modify system properties. d. This method determines whether the permission with the specified permission target name should be granted or denied. 5. Which of the following areas aren’t controlled by the security manager? a. Creating subprocesses. b. Opening large number of oversized windows. c. Performing intensive calculations. d. Accessing or modifying system properties.

Short Questions 1. Explain the process of specifying the security manager for your Java application. 2. Compare the checkPropertyAccess() and checkPropertiesAccess() methods. 3. How does opening a large number of windows affect CPU time and memory?


Chapter 6

Answers Multiple Choice Answers 1. a, c, and d. The SecurityManager class contains many methods preceded with the check keyword. If the check proceeds normally, the corresponding check method throws a SecurityException. By default, Java applications run without any security manager. 2. a, b, and d. You can specify the security manager for your Java application by specifying a command-line option and activating the security manager in your application code. You can set the default security manager for your application by using the -Djava.security.manager option on the command line. 3. a, b, and c. The checkConnect() method determines whether the calling thread is allowed to open a socket connection with the specified host and port number. The checkListen() method determines whether the calling thread can wait for a specified connection request on the given local port. The checkSetFactory() method determines whether the calling thread is allowed to set the socket factory used by the ServerSocket or Socket class. 4. c. The checkPropertiesAccess() method determines whether the calling thread is allowed to access or modify system properties. 5. b and c. Security manager has the checkPropertiesAccess() method, which controls access on system properties. The checkExec() method determines whether the calling thread is allowed to create a subprocess.

Short Answers 1. You can specify the security manager for your Java application by the following two methods. • Specifying a command-line option • Activating the security manager in your application code You can set the default security manager for your application by using the Djava.security.manager option on the command line. The default security manager imposes restrictions similar to those placed on applets, thereby preventing most of the sensitive operations from being performed. For example, if you wanted to set the default security manager for your Java application, myWebApp, you would use the following command. java -Djava.security.manager myWebApp

143

144

Part II


In the second method, you can activate the security manager in your application code by using the setSecurityManager() method of the System class. Consider the following code snippet: public static void main(String[] args) { SecurityManager myManager = new SecurityManager(); System.setSecurityManager(myManager)

2. The checkPropertyAccess() method determines whether the calling method is allowed to access the system property with the specified key name. This method is used when an object of the class System calls its getProperty() method. The method definition is public void checkPropertyAccess(String key). The key parameter is a system property key. This method invokes the checkPermission() method with the PropertyPermission(key, “read”) permission as its parameter. The checkPropertiesAccess() method checks whether the calling thread is allowed to access or modify system properties. This method is invoked when an object of the System class calls its getProperties() and setProperties() methods. The method definition is public void checkPropertiesAccess(). This method invokes the checkPermission() method with the PropertyPermission(“*”, “read,write”) permission as its parameter. 3. Opening a large number of oversized windows might prove to be a much more serious attack as compared to the denial-of-service attacks. These windows render the keyboard and mouse useless when they pop up on the screen. When multiple windows are being created, a few untrusted windows might pop up without any warning. These multiple windows cause the window manager’s event queue to be filled up. This disables the keyboard and mouse, which also use window events to interact with the computer. Crackers can use these windows to solve their malicious purposes. For example, imagine a cracker who writes code that generates an imitation of a password window. Users unknowingly enter their user IDs and passwords, which are captured by a malicious applet and sent to the cracker’s site, where they are stored for future use. Therefore, a user can be easily fooled through such attacks.

Chapter 7 The Access Controller and Permissions in Java 2

I

n the previous chapter, you learned about the security manager and the access controller, which was introduced in Java 2. In earlier versions of Java, the security manager alone created customized security policies for the system. However, in Java 2, the security manager passes on the access control decisions to the access controller. The Java API still calls the check methods of the security manager to enforce security. However, these methods, in turn, call the checkPermission() method of the AccessController class. Therefore, the access controller provides a single method for applying fine-grained access control. The access controller also determines the permissions needed by a program to access resources. I’ll discuss the role of the access controller and permissions in detail in this chapter.

The AccessController Class The java.security package contains the AccessController class in Java 2 that performs the following functions: ◆ It refers to the default security policy to determine whether access to a valu-

able system resource is allowed. ◆ It marks certain code as “privileged”, thereby affecting the resource access

permissions defined for the code. ◆ It stores a picture of the current calling context. This helps the access con-

troller to take access control decisions from a different context with respect to the current context. You are already aware of the checkPermission() method of the AccessController class. Let’s recall it. The checkPermission() method determines whether the resource access request by a specific permission is to be granted. If the access to a requested resource is granted, the checkPermission() method returns back. On the other hand, if the access is denied, AccessControlException is thrown. In the subsequent section, I’ll discuss the methods of the AccessController class.

THE ACCESS CONTROLLER AND PERMISSIONS IN JAVA 2

Chapter 7

Methods of the AccessController Class The following is the list of methods in the AccessController class: ◆ checkPermission(Permission perm) ◆ doPrivileged(PrivilegedAction action) ◆ doPrivileged(PrivilegedAction action, AccessControlContext context) ◆ doPrivileged(PrivilegedExceptionAction action) ◆ doPrivileged(PrivilegedExceptionAction action, AccessControlContext context) ◆ getContext()

Now, let’s discuss these methods in detail.

The checkPermission(Permission perm) Method I have already discussed the checkPermission(perm) method in brief. Now, let’s discuss it in detail. The definition for this method is specified here: public static void checkPermission(Permission perm) throws AccessControlException

AccessControlException is thrown only if the permission contains an invalid value

or is of an incorrect type. This indicates that it is an unchecked exception. Consider a scenario where the current thread passes through x callers starting from callers 1 to x. Then, the checkPermission() method is invoked by caller x. The checkPermission() method decides the resource access status on the basis of the following algorithm: i=x; while(i>0) { if(caller i does not have the specified permission in its protection domain) throw AccessControlException else if(caller i contains privileged code) { if(doPrivileged method with context parameter is called) context.checkPermission(perm) return;

147

148

Part II


} i=i-1; }; //Check the context inherited on creation of a new thread. // AccessControlContext associated with the new thread is // stored as the inherited context. inheritedContext.checkPermission(permission);

If the caller is marked as privileged, the checkPermission() method stops checking the code and returns back. A caller is marked as privileged via a doPrivileged() call. The usage of the doPrivileged() method is discussed in the subsequent sections.

The doPrivileged(PrivilegedAction action) Method The definition for this method is specified here: public static Object doPrivileged(PrivilegedAction action)

This method performs the specified PrivilegedAction action with all the privileges enabled. The specified action is performed with all the permissions specified in the protection domain of the calling function. The parameter passed to this method is the action that needs to be performed. This method returns the value retuned by the run() method of the specified action.

NOTE The PrivilegedAction interface object is used to perform computations with privileges enabled. The specified computation is performed by invoking the AccessController.doPrivileged() method on the PrivilegedAction object. This interface is used only for those computations that do not throw checked exceptions.

The doPrivileged(PrivilegedAction action, AccessControlContext context) Method The definition for this method is specified here: public static Object doPrivileged(PrivilegedAction action, AccessControlContext context)

This method performs the specified PrivilegedAction action with all the privileges enabled. However, the action is also restricted by the specified AccessControlContext


Chapter 7

context. When the specified action is performed, it is controlled by both the permissions specified by the protection domain of the caller and those specified by the AccessControlContext domain. As seen in the preceding syntax, there are two parameters passed to this method, namely action and context. Here, action specifies the action to be performed; context indicates an access control context, which specifies the restrictions to be applied to the privileges of the caller domain before performing the specified action. The method returns the value as specified by the run method of the action.

The doPrivileged(PrivilegedExceptionAction action) Method The definition for this method is specified here: public static Object doPrivileged(PrivilegedExceptionAction action) throws PrivilegedActionException

This method performs the specified PrivilegedExceptionAction action with privileges enabled. The action is performed with all the permissions specified in the protection domain of the caller. The parameter passed to this method is the action to be performed and it returns the value specified by the run method of the action.

NOTE The PrivilegedExceptionAction interface is used only for those computations that throw checked exceptions. Computations that do not throw checked exceptions should use the PrivilegedAction instead.

The doPrivileged(PrivilegedExceptionAction action, AccessControlContext context) Method The definition for this method is specified here: public static Object doPrivileged(PrivilegedExceptionAction action, AccessControlContext context) throws PrivilegedActionException

This method performs the specified PrivilegedExceptionAction action with all the privileges enabled. However, the action is also restricted by the specified AccessControlContext context. When the specified action is performed, it is controlled both by the permissions specified by the protection domain of the caller and those specified by the AccessControlContext domain.

149

150

Part II


The getContext() Method The definition for this method is specified here: public static AccessControlContext getContext()

This method captures the current calling context. It captures the inherited AccessControlContext context of the current thread, and places it in an AccessControlContext object. It finally returns this object. I’ve discussed the various methods of the AccessController class in this section. Now, let’s discuss how to write privileged code by using these methods.

Writing Privileged Code The caller of a specified resource request can be marked as privileged. The checkPermission() method makes access control decisions; however, it stops checking if the caller is marked as privileged. The caller is marked as privileged by calling the doPrivileged() method without the context argument. If the protection domain of the caller contains the specified permission, the checkpermission() method returns back normally. This indicates that no further checking is done and the resource is allocated to the specified caller. However, if the specified permission is missing in the protection domain of the caller, an exception is raised. Consider a scenario when you do not need to return any value from the privileged block. Observe the outline code for such a situation: callerMethod() { normal code statements AccessController.doPrivileged(new PrivilegedAction() { public Object run()

{

//add privileged code here return null; } }); normal code statements

}

In the preceding code, the PrivilegedAction instance acts as an interface with the run() method that returns an Object. Therefore, when the doPrivileged() method is called, this instance is passed to it as a parameter. The doPrivileged() method


Chapter 7

takes an instance of the PrivilegedAction class and invokes its run() method in privileged mode. The run() method is called after enabling privileges. The privileges are revoked after the run() method is executed. The preceding code can also be implemented without using the inner class. In this case, you create a class based on the PrivilegedAction class and pass an instance of this class to the doPrivileged() method. The implementation of such privileged code is given here: callerMethod() { //normal code statements tryAction act = new tryAction(); //assign privileges to this instance AccessController.doPrivileged(act); } class tryAction implements PrivilegedAction { public tryAction() {}; public Object run() { //add privileged code here System.loadLibrary(“awt”); return null; } }

You need to modify the inner classes based on the contents of the privileged code. For example, if the privileged code accesses local variables or throws an exception, you need to make changes to the preceding code snippets. Let’s discuss the case when privileged code needs to return values. There are multiple ways of writing privileged code that returns certain values such as the system property, user.home, which represents the home directory of the user. Consider the code given here: callerMethod() { //normal code statements String userHome = (String) AccessController.doPrivileged (new PrivilegedAction() { public Object run()

{

151

152

Part II


//add privileged code here return System.getProperty(“user.home”); } }); normal code statements

}

The preceding code returns the home directory of the user by the doPrivileged() method. However, the preceding code requires a dynamic cast on the value returned by this method. You can avoid this cast by using a class that handles type casting for you. The code for such a class is specified here: callerMethod() { //normal code statements GetSystemProperty gsp = new GetSystemProperty (“user.home”); AccessController.doPrivileged(gsp); String userHome = gsp.fetchValue(); //normal code statements }

class GetSystemProperty implements PrivilegedAction { private String sysproperty; private String propvalue; public GetSystemProperty (String sysprop) { sysproperty = sysprop;} public Object run() { propvalue = System.getProperty(sysproperty); return propvalue; } public String fetchValue() {return propvalue;}

}

In the preceding section, you must have noted that the doPrivileged() method is overloaded. If the run() method throws an exception, you can use the doPrivileged() method with the PrivilegedExceptionAction interface. Let’s consider the code snippet given here: callerMethod() throws FileNotFoundException{ //normal code statements try{


Chapter 7

FileInputStream fis = (FileInputStream) AccessController.doPrivileged ( new PrivilegedExceptionAction() { public Object run() throws FileNotFoundException { return new FileInputStream(“abcFile”); } } ); } catch (PrivilegedActionException e) { throw (FileNotFoundException) e.getException(); } //normal code statements }

In the preceding code, the getException() method returns an Exception object. This object is cast to the specific exception to be thrown. In the preceding code, it is cast to FileNotFoundException. This is necessary because only checked exceptions can be wrapped in PrivilegedActionException. Checked exceptions are exceptions specified in the throws clause Therefore, PrivilegedActionException is a wrapper for exceptions thrown by privileged actions. Now, let’s consider the case when you need to access local variables in privileged code. The local variables that you use in an anonymous inner class need to be declared as final. Consider the code given here: callermethod() { //normal code statements here final String libr = “awt”; AccessController.doPrivileged(new PrivilegedAction() { public Object run() { // add privileged code here System.loadLibrary(libr); return null; } }); //normal code statements here }

However, if the libr variable needs to be modified multiple times in the program, it cannot be declared as final. In such a case, you can create a new variable before invoking the doPrivileged() method, declare it as final, and set it equal to the earlier variable. Observe the code given here:

153

154

Part II


callermethod() { //normal code statements here String libr = “awt”; // libr cannot be declared as final because it is set to //

different values multiple times. final String flibr = libr; AccessController.doPrivileged(new PrivilegedAction() { public Object run() { // add privileged code here System.loadLibrary(flibr); return null; } }); //normal code statements here }

Now, I’ll discuss permissions in Java, which also help in fine-grained access control.

Permissions in Java 2 Permissions specify the access to various system resources. The various permissions are derived from the abstract class, java.security.Permission. You need to define permissions for accessing various system resources in a Java program. For example, if a Java program attempts to write to the file myFile from the myDocs directory, you need to provide the following permission in the program for error-free execution. perm = new java.io.FilePermission(“/myDocs/myFile”, “write”);

Subclassed permissions do not belong to a common package; instead they belong to packages depending on their function. In the preceding example, note that FilePermission belongs to the java.io package. You can add new application-specific permissions in addition to the built-in permissions. I’ll discuss this in a subsequent section. Now I’ll discuss more about the built-in permission classes in Java 2.

Built-in Permissions You are already aware that most of the permissions are derived from the abstract class, java.security.Permission. In addition to this class, there is an abstract class java.security.PermissionCollection and a final class java.security.Permissions. An instance of the PermissionCollection class holds permissions of the same type. It


Chapter 7

is used to store Permission objects of a single category such as Net permissions. On the other hand, the Permissions class is a collection of PermissionCollection objects. Now, I’ll discuss the syntax of the built-in permissions in Java 2.

The java.security.Permission Class The Permission class acts as a parent for all permissions. It contains the basic functionality needed for all permissions. All permissions have a name and abstract functions for defining the particular Permission subclass. Most permission objects also contain an actions list that specifies the actions permitted for the object. For example, a java.io.FilePermission object contains the target at which the permission is aimed, such as the file name, and the action for which the permission is required, such as read or write. However, the actions list is optional for certain Permission objects, such as java.lang.RuntimePermission objects. All the subclasses created from the Permission class must implement the implies() method, which is used to compare permissions. For example, consider the code statement given here: permission p1 implies permission p2

The preceding statement indicates that if a program is granted permission p1, it is also granted permission p2. The built-in classes that are directly derived from the Permission class are as follows: ◆ java.security.AllPermission ◆ java.net.SocketPermission ◆ java.io.FilePermission ◆ java.security.UnresolvedPermission ◆ java.security.BasicPermission

Now, I’ll discuss each of these in detail.

The java.security.AllPermission Class This class implies all permissions. It also includes the permissions that might be added later. System administrators generally use this permission because they perform multiple tasks, most of which require permissions. Therefore, it would be redundant if the security policy had to iterate through all the permissions. The AllPermission class disables security restrictions by granting all the permissions. Therefore, this class should be used sparingly and with much care. Security considerations should be kept in mind before granting this permission. This permission should be granted only to

155

156

Part II


trusted applets or applications where adding all permissions would make the security policy file bulky.

The java.net.SocketPermission Class This permission indicates access to a network through sockets. An instance of the SocketPermission class contains a host specification and the actions, which specify connection with the host. The host specification includes the host name and the port range. The actions on sockets include accept, connect, listen, and resolve. The accept and connect actions should be granted permissions after much thought because this means opening doors to malicious code for entering and attacking your system.

The java.io.FilePermission Class This class indicates the permissions for actions on files. The class contains a path name and a set of actions for the file specified in the path name. The path name indicates the file or directory, which is subject to the specified actions. If the path name contains directory/*, it indicates all the files in the specified directory. An asterisk (*) represents all the files in the current directory. The string specifies all the files in the file system. Permissions for actions represented by the string must be considered for security before being granted. The actions specified in the FilePermission class are read, write, delete, and execute.

Consider the following code statement: FilePermission p = new FilePermission(“/myDocs/myDir/”, “read”);

The preceding code statement only lists all the files in the specified directory. It does not allow you to read all the files in the specified directory. For this you’ll have to modify the preceding code statement as given here: FilePermission p = new FilePermission(“/myDocs/myDir/*”, “read”);

NOTE By default, code has permissions to read files and directories from its originating URL location. You don’t need to explicitly specify permissions for these files, which reside in the same directory as the source code.


Chapter 7

The java.security.UnresolvedPermission Class When a policy is initialized, there are certain permissions whose actual Permission class does not exist at this time. Such permissions are called unresolved permissions. This situation generally arises when the code that implements the specified permission class is not loaded in the Java environment. Therefore, the UnresolvedPermission class stores information about these unresolved permissions in the policy file. When the checkPermission() method is called in the case of an unresolved permission, it is checked to determine whether the associated class has been loaded. If the class has been loaded, the permissions of the specified type are resolved. In other words, a new object of the loaded type is instantiated with the information contained in the UnresolvedPermission class and this object replaces the UnresolvedPermission instance. If the UnresolvedPermission instance cannot be resolved, the permission is considered invalid.

The java.security.BasicPermission Class The BasicPermission class is used as the base class for classes that want the same naming convention as this class. The name for an instance of this class is same as the name of the specified permission. This class is used as the base class for permissions that have only names and no action list. However, the subclasses that are derived from this class can implement actions, if required. Following are the classes that are derived from the Permission class through the BasicPermission class. ◆ java.lang.RuntimePermission ◆ java.security.SecurityPermission ◆ java.util.PropertyPermission ◆ java.net.NetPermission ◆ java.io.AWTPermission ◆ java.lang.reflect.reflectPermission ◆ java.io.SerializablePermission

Now, I’ll discuss these permissions in detail.

The java.lang.RuntimePermission Class In this class, there is no action associated with the target name specified in the constructor. For example, RuntimePermission(“modifyThread”) grants permission to

157

158

Part II


modify the current thread. The RuntimePermission class takes the following target names: ◆ exitVM ◆ modifyThread ◆ stopThread ◆ modifyThreadGroup ◆ queuePrintJob ◆ createClassLoader ◆ getClassLoader ◆ setContextClassLoader ◆ createSecurityManager ◆ setSecurityManager ◆ setFactory ◆ setIO ◆ getProtectionDomain ◆ readFileDescriptor ◆ writeFileDescriptor ◆ loadLibrary.{library name} ◆ accessClassInPackage.{package name} ◆ defineClassInPackage.{package name} ◆ accessDeclaredMembers.{class name}

The java.security.SecurityPermission Class This class is also derived from the BasicPermission class and does not contain any specified actions. The SecurityPermission class controls the access to Policy, Security, Provider, Signer, and Identity objects. It is basically used to assign security permissions. The target name contained in a SecurityPermission class instance is a security configuration parameter. A few of these parameters are listed here: ◆ setIdentityPublicKey ◆ setIdentityInfo ◆ printIdentity ◆ addIdentityCertificate ◆ removeIdentityCertificate ◆ getPolicy


Chapter 7

◆ setpolicy ◆ insertProvider.{provider name} ◆ removeProvider.{provider name} ◆ getProperty.{key} ◆ setProperty.{key}

The java.util.PropertyPermission Class The PropertyPermission class is one of the subclasses of the BasicPermission class, which implements actions as well. This class is used for setting property permissions. The target names for this class are names of various Java properties, such as java.home and os.name. You can also use wildcards while specifying property names. However, please note that the wildcard can occur only once and be at the extreme right position. For example, * signifies any property and c.* signifies any property name prefixed with “c”. The actions associated with the PropertyPermission class are read and write. The read action allows the call to the getProperty method that gets the specified property value. The write action allows the call to the setProperty method to set the specified property value.

CAUTION Code should be granted permissions to access certain system properties only after considering their usage. For example, imagine malicious code having access to the java.home, user.name, and user.home system properties. This indicates that the malicious code has access to sensitive information regarding the system and user environment and can tamper or crash the system.

The java.net.NetPermission Class The NetPermission class is used to assign various network permissions. Like all other subclasses of the BasicPermission class, the NetPermission class does not have any actions associated with it. It only contains target names and no associated actions. The targets supported by this permission are listed here: ◆ requestPasswordAuthentication ◆ specifyStreamHandler ◆ setDefaultAuthenticator

159

160

Part II


The java.io.AWTPermission Class The AWTPermission class is used for assigning Abstract Window Toolkit (AWT) permissions. This permission class only contains the target names and no associated actions. The target name is the name of the specified AWT permission. Following is the list of such target names: ◆ accessEventQueue ◆ accessClipboard ◆ showWindowWithoutWarningBanner ◆ readDisplayPixels ◆ listenToAllAWTEvents

The java.lang.reflect.reflectPermission Class This permission class is used for reflective operations. It is a named permission with no defined actions. It has just one target name specified, suppressAccessChecks, which suppresses the Java language access checks. These access checks are public, private, and protected and are performed by reflected objects.

The java.io.SerializablePermission Class This class is used for assigning serializable permissions with target names and no specified actions. The target names for this class are as follows: ◆ enableSubstitution ◆ enableSubclassImplementation

Permission Implications You are already aware of the fact that permission are derived from the Permission class with the implies() method. This method compares permissions and defines the relation of a particular permission class with remaining permission classes. For example, consider the following code statement: java.io.FilePermission(“/myDocs/*”,“read”);

The preceding code statement implies the permission, java.io.FilePermission(“/myDocs/myFile”,“read”); however, it does not imply the java.net.SocketPermission class. There are layers of implication, which are not as direct as the ones discussed previously. For example, consider an application that has been assigned the permission to


Chapter 7

write to the entire file system. This implies that the specified application has access to all Java system files including the Java runtime environment. Therefore, you do not need to assign a specified PropertyPermission for this. The specified application has indirectly been granted full permissions. There are various examples, which further implicate the permissions granted to a specified applet or application. Therefore, a particular permission simultaneously grants access to resources associated with it. For example, if you assign the runtime permission to modify threads, you also assign the remaining permissions associated with this action. Other dangerous permissions include those that allow you to set system properties or those that allow you to specify runtime permissions for specifying packages. AllPermission is the most dangerous of them all. Therefore, before assigning permissions to applets or applications, you need to consider the serious implication behind doing so. In the subsequent section, I’ll discuss how to create custom permission types.

Custom Permission Types The built-in permission types cover almost all of the valued resources with which JVM can interact. However, there are situations when you might need to create custom permission types to extend the capabilities of the predefined permission types. You can create custom permission types by extending one of the basic permission types. You generally extend the Permission or BasicPermission class. Then, you need to concentrate on implementing the implies(), equals(), or hashCode() methods of these classes. Finally, the new class is included in the application package. The code of the application calls the access controller when a resource request is placed. Then, the AccessController.checkPermission() method is called. In earlier versions of Java, when you had to check a new resource access, a new method had to be added to the security manger. However, in Java 2, all you have to do is create a customized Permission class for the same. Let’s consider a scenario for creating custom permission types. Imagine a banking scenario where the customer account information is considered sensitive. Not everyone has access to this sensitive information. Therefore, this information needs to be protected by extra permission types. I’ll discuss creation of a custom permission type to protect this sensitive data. I’ll create a custom permission type called MyAccPermission, which protects access to a customer account file MyAccFile in the C:\AccInfo\ directory. Then, I’ll create a test

161

162

Part II


program that checks this custom permission type. The default policy file needs to be updated to contain the FilePermission and the custom permission, MyAccPermission. Following is the code listing for the MyAccPermission.java file: import java.security.*; import java.io.*; public class MyAccPermission extends BasicPermission { public MyAccPermission(String name) { super(name); System.out.println(“The MyAccPermission constructor (String name) is called”); } public MyAccPermission(String name, String actions) { super(name); System.out.println(“The MyAccPermission constructor (String name, String actions) is called”); } }

Note that in the preceding code the custom permission is extended from the BasicPermission class and not the Permission class. This is because the implementation of the BasicPermission class is much simpler as you have to only provide the target specification. In addition, this class also provides a default implementation of the Permission.implies() method. However, you need to specify two constructors in the custom permission type definition. The preceding code specifies a constructor that contains only the target name and another that contains both the target name and the actions associated with it. Both these constructors are called, although you used only one to instantiate a MyAccPermission object. The second constructor is used by the Policy object to instantiate objects of the new permission class. I’ll write a test program, which will test the new permission, MyAccPermission. import java.io.*; import java.security.*; public class TestAccPermission { public static void main(String args[])


Chapter 7

{ try { SecurityManager MyManager = System.getSecurityManager(); if(MyManager != null) MyManager.checkPermission(new MyAccPermission (“TestAccPermission”)); File inFile = new File(“C:\\AccInfo\\MyAccFile.txt”); FileInputStream fis = new FileInputStream(inFile); InputStreamReader isr = new InputStreamReader(fis); BufferedReader br = new BufferedReader(isr);

String line; while((line = br.readLine())!=null) System.out.println(line); } catch(Exception e) { e.printStackTrace(); } } }

The main() method of the preceding test program determines whether the security manager is null. The custom permission is accessed only if the security manager is not null. Note that in the preceding code, the checkPermission() method performs security checks in the currently executing thread. The parameter passed to this method is the requestor of a resource. This method checks the current security policy for the specified permission. If the permission exists, the method returns back normally; otherwise it raises an AccessControlException. The policy file should contain the following grant entries for error-free execution of the test program: grant codeBase “file:/C:/AccInfo/” { permission java.io.FilePermission “C:\\AccInfo\\MyAccFile.txt”, “read”; permission MyAccPermission “TestAccPermission”; }

163

164

Part II


The preceding entry signifies that the test program would execute even if the security manager were not specified. However, the custom permission will be accessed only if the current security manager is not null. Now, I’ll execute the test program without invoking the security manager by typing the following statement at the command prompt: java TestAccPermission

The output is shown in Figure 7-1. The preceding output confirms that the test program works even without the security manager. However, the constructors of the MyAccPermission class are not called. This is because the custom permission, MyAccPermission, is called only when the security manager is not null. Now, I’ll execute the test program with the default security manager by typing the following code statement at the command prompt: java -Djava.security.manager TestAccPermission

The output is shown in Figure 7-2. Note that AccessControlException is raised on execution of the test program with the security manager. Recall that the grant entry in the policy file contained the text, codeBase “file:/C:/AccInfo/”, indicating that the permissions specified in the grant entry were assigned to the AccInfo directory.

FIGURE 7-1 The output of the TestAccPermission.java file without

invoking the security manager


Chapter 7

FIGURE 7-2 The output of the TestAccPermission.java file while

using the security manager

However, I was executing the test program from the C:\ as can be seen in Figure 72. Therefore, for error-free execution of the program, the custom permission, MyAccPermission, and the test program, TestAccPermission, need to be moved to the AccInfo directory. Now, I’ll execute the test program from the AccInfo directory. The output is shown in Figure 7-3. As seen in Figure 7-3, the constructors of the MyAccPermission class are invoked and the contents of the MyAccFile.txt are displayed.

FIGURE 7-3 The error-free execution of the TestAccPermission.java

file while using the security manager

165

166

Part II


Summary In this chapter, I discussed the AccessController class along with its methods. I also explained how to write privileged code. Then, I talked about permissions in Java 2 and also discussed all the built-in permission classes in Java. Next, I talked about the implications of assigning permissions. Finally, I explained the creation of custom permission types in Java.

Check Your Understanding Multiple Choice Questions 1. What happens if the caller of the checkPermission() method is marked as privileged? a. AccessControlException is thrown. b. The checkPermission() method stops checking the code. c. The specified PrivilegedExceptionAction action is performed with privileges enabled. d. The resource access status is not checked. 2. Which of the following method(s) marks a caller as privileged? a. checkPermission() b. getContext() c. doPrivileged() d. run() 3. Which of the following statement(s) is true? a. Permissions are derived from the java.security.PermissionCollection class. b. An instance of the Permissions class holds permissions of the same type. c. The Permissions class is a collection of PermissionCollection objects. d. The java.security.Permissions class is a final class. 4. Which of the following does not hold true for the AllPermission class? a. The AllPermission class disables security restrictions by granting all the permissions. b. The AllPermission class can be used with almost all applets and applications. c. The AllPermission class makes the security file lighter.


Chapter 7

d. The AllPermission class is used by system administrators because they perform multiple tasks, most of which require permissions. 5. Which class is used as the base class for permissions that have only names and no action list? a. java.security.AllPermission b. java.security.Permission c. java.security.BasicPermission d. java.security.SecurityPermission 6. Which of the following statement(s) hold true while creating custom permission types? a. You extend the Permission or BasicPermission class. b. You extend the SecurityPermission class. c. You implement the implies(), equals(), or hashCode() methods. d. You implement the run() method.

Short Questions 1. What do permission implications mean? 2. Discuss the java.security.UnresolvedPermission class. 3. Write the code for a custom permission type, MyTrialPermission.

Answers Multiple Choice Answers 1. b. If the caller is marked as privileged, the checkPermission() method stops checking the code and returns. 2. c. The caller is marked as privileged by calling the doPrivileged() method without the context argument. 3. c and d. Most of the permissions are derived from the abstract class, java.security.Permission. In addition to this class, there is an abstract class java.security.PermissionCollection and a final class java.security.Permissions. An instance of the PermissionCollection class holds permissions of the same type. It is used to store Permission objects of a single category such as Net permissions. On the other hand, the Permissions class is a collection of PermissionCollection objects.

167

168

Part II


4. b. The AllPermission class disables security restrictions by granting all the permissions. Therefore, this class should be used sparingly. Security considerations should be kept in mind before granting this permission. This permission should be granted only to trusted applets or applications where adding all permissions would make the security policy file bulky. 5. c. The java.security.BasicPermission class is used as the base class for permissions that have only names and no action list. 6. a and c. While creating custom permission types, you generally extend the Permission or BasicPermission class. Then, you need to concentrate on implementing the implies(), equals(), or hashCode() methods of these classes. Finally, the new class is included in the application package.

Short Answers 1. All the subclasses created from the Permission class must implement the implies() method, which is used to compare permissions. For example, consider the following code statement: permission p1 implies permission p2

This statement indicates that if a program is granted permission p1, it is also granted permission p2. This method compares permissions and defines the relation of a particular permission class with remaining permission classes. There are layers of implication, which are not always direct. For example, consider an application that has been assigned the permission to write to the entire file system. This implies that the specified application has access to all Java system files including the Java runtime environment. Therefore, you do not need to assign a specified PropertyPermission for this. The specified application has indirectly been granted full permissions. There are various examples, which further implicate the permissions granted to a specified applet or application. Therefore, a particular permission simultaneously grants access to resources associated with it. For example, if you assign the runtime permission to modify threads, you also assign the remaining permissions associated with this action. Other dangerous permissions include those that allow you to set system properties or those that allow you to specify runtime permissions for specifying packages. AllPermission is the most dangerous of them all. Therefore, before assigning permissions to applets or applications, you need to consider the serious implication behind doing so. 2. When a policy is initialized, there are certain permissions whose Permission class does not exist at this time. Such permissions are called unresolved permissions. This situation generally arises when the code that implements the


Chapter 7

specified permission class is not loaded in the Java environment. Therefore, the UnresolvedPermission class stores information about these unresolved permissions in the policy file. When the checkPermission() method is called in the case of an unresolved permission, it is checked to determine whether the associated class has been loaded. If the class has been loaded, the permissions of the specified type are resolved. In other words, a new object of the loaded type is instantiated with the information contained in the UnresolvedPermission class and this object replaces the UnresolvedPermission instance. If the UnresolvedPermission instance cannot be resolved, the permission is considered invalid. 3. The code for the custom permission type, MyTrialPermission, is given here: import java.security.*; import java.io.*; public class MyTrialPermission extends BasicPermission { public MyTrialPermission (String name) { super(name); System.out.println(“The MyTrialPermission constructor (String name) is called”); } public MyTrialPermission (String name, String actions) { super(name); System.out.println(“The MyTrialPermission constructor (String name, String actions) is called”); } }

169


Chapter 8 Security Configuration Files and Security APIs

T

he security features in Java have changed across various versions. As you have read in the preceding chapters, there have been many changes in the security model in Java 2. The security file, java.security, and the policy file, java.policy, are the primary security configuration files of JVM. There have been changes in these files also. These files are stored in the java.home/lib/security directory after the installation of the Java 2 SDK. You can update or rewrite these files after the installation. These configuration files are used to define the security policies and access permissions. There is another security file that is stored in this directory, the cacerts file. Java 2 also includes certain security packages that help you build secure applications. I’ll discuss these security files and the security APIs in this chapter.

The Security Properties File This file is used to set the various security properties that are used by the classes in the java.security package. The listing of this file is given here: # # This is the “master security properties file”. # # In this file, various security properties are set for use by # java.security classes. This is where users can statically register # Cryptography Package Providers (“providers” for short). The term # “provider” refers to a package or set of packages that supply a # concrete implementation of a subset of the cryptography aspects of # the Java Security API. A provider may, for example, implement one or # more digital signature algorithms or message digest algorithms. # # Each provider must implement a subclass of the Provider class. # To register a provider in this master security properties file, # specify the Provider subclass name and priority in the format # #

security.provider.=

# # This declares a provider, and specifies its preference

SECURITY CONFIGURATION FILES AND SECURITY APIS

Chapter 8

# order n. The preference order is the order in which providers are # searched for requested algorithms (when no specific provider is # requested). The order is 1-based; 1 is the most preferred, followed # by 2, and so on. # # must specify the subclass of the Provider class whose # constructor sets the values of various properties that are required # for the Java Security API to look up the algorithms or other # facilities implemented by the provider. # # There must be at least one provider specification in java.security. # There is a default provider that comes standard with the JDK. It # is called the “SUN” provider, and its Provider subclass # named Sun appears in the sun.security.provider package. Thus, the # “SUN” provider is registered via the following: # #

security.provider.1=sun.security.provider.Sun

# # (The number 1 is used for the default provider.) # # Note: Statically registered Provider subclasses are instantiated # when the system is initialized. Providers can be dynamically # registered instead by calls to either the addProvider or # insertProviderAt method in the Security class.

# # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider

# # Class to instantiate as the system Policy. This is the name of the class # that will be used as the Policy object. # policy.provider=sun.security.provider.PolicyFile

# The default is to have a single system-wide policy file,

173

174

Part II


# and a policy file in the user’s home directory. policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy

# whether or not we expand properties in the policy file # if this is set to false, properties (${...}) will not be expanded in policy # files. policy.expandProperties=true

# whether or not we allow an extra policy to be passed on the command line # with -Djava.security.policy=somefile. Comment out this line to disable # this feature. policy.allowSystemProperty=true

# whether or not we look into the IdentityScope for trusted Identities # when encountering a 1.1 signed JAR file. If the identity is found # and is trusted, we grant it AllPermission. policy.ignoreIdentityScope=false

# # Default keystore type. # keystore.type=jks

# # Class to instantiate as the system scope: # system.scope=sun.security.provider.IdentityDatabase

# # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission (“accessClassInPackage.”+package) has # been granted. package.access=sun.


Chapter 8

# # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission (“defineClassInPackage.”+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition=

The preceding code listing has many comments and very few entries in the security properties file. Let’s observe these entries without the comments that actually explain them. security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider policy.provider=sun.security.provider.PolicyFile policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy policy.expandProperties=true policy.allowSystemProperty=true policy.ignoreIdentityScope=false keystore.type=jks system.scope=sun.security.provider.IdentityDatabase package.access=sun. #package.definition=

I’ll now explain the default entries in the security properties file in detail.

Security Providers Observe the following entry: security.provider.1=sun.security.provider.Sun

The preceding entry defines the cryptographic package providers along with their locations and preference orders. These providers offer a cryptographic implementa-

175

176

Part II


tion to the Java security API. There must be at least one security provider specification in the security properties file. If another provider needs to be defined, it should be specified as: security.provider.=

The preceding statement adds the provider with preference order n. The providers are ordered starting from 1 to n. In such a multi-provider implementation, the provider with higher preference is chosen. The security engine looks for the desired implementation in the list of providers starting from the first one in the list. If the given provider matches its requirements, it does not search further. However, it continues to search through the provider list until the desired implementation is met. The keyword in the preceding code statement defines the subclass of the Provider class. The constructor of the Provider class sets the values of the different properties that are required by the Java security API to locate the facilities implemented by providers. The Provider subclasses are instantiated when the system is initialized. SUN is the default provider with Java 2. Its Provider subclass is named Sun. Both of these are part of the sun.security.provider package. The SUN provider offers the following services: ◆ The JKS keystore implementation for the proprietary keystore type ◆ An implementation of the Digital Signature Algorithm (DSA) ◆ A DSA key pair generator for generating key pairs for the DSA algorithm ◆ A DSA algorithm parameter generator ◆ A DSA algorithm parameter manager ◆ A DSA key factory ◆ A certificate factory for X.509 certificates and Certificate Revocation Lists

(CRLs) You’ll read more about security provider implementation in Chapter 12, “Introduction to Cryptography.”

Policy Providers The policy.provider entry in the security properties file specifies the file that will be used to instantiate the system policy. This entry defines the class name to be used as the Policy object that defines the permissions available for the specified code source. The code source contains the URL location of the code and the certificates of the entities that have signed the code.


Chapter 8

The default value contained in this entry is sun.security.provider.PolicyFile. The PolicyFile class of the sun.security.provider package defines the Java 2 SDK policy implementation.

Policy File URL Locations The URL locations of policy files are defined in the security properties file through the value of properties that are defined as: policy.url.n=URL

In the preceding code statement, n stands for the precedence number of the policy file to be considered. URL points to the path of the policy file associated with the precedence number. By default, there are two URL locations for policy files, namely a system-wide policy file in the location file:/${java.home}/lib/security/java.policy and the user-defined policy file in the location file:${user.home}/.java.policy. Other than these two URL locations, you can also specify an ordered list of URLs for the policy files to load. The order of these policy files is 1-based. This indicates that if there are policy files starting from 1 to n, the policy.url.1 file is read first. The precedence numbers must be in serial order and continuous. If they are not so, the policy files that break the serial order are ignored. For example, consider the policy files: policy.url.1, policy.url.2, and policy.url.4. In this case, only the files, policy.url.1 and policy.url.2, are considered and the policy.url.4 file is ignored. Therefore, when the Policy class is initialized, the system policy is added to it followed by the user policy. You can also add customized policy files, as specified by the path given here: policy.url.3=file:/C:/niit/niitpolicy

Policy files need not be confined to the local system. They can also be stored on remote systems and then be accessed by specifying the URL path. Therefore, system administrators install a system-wide policy file on a policy server, which can be accessed by the client computers that also store their local user-defined policy files.

Policy File Property Expansion This entry in the security properties files determines whether property expansion should be allowed in policy files. The syntax of the property expansion entry is specified here: policy.expandProperties=boolean

177

178

Part II


If the preceding security property is set to true, it indicates that the system property variables, such as ${java.home} and ${user.home}, are translated into their respective values every time they appear in a policy file. On the other hand, if this property is set to false, the system property variables are not expanded. They have to be hardcoded. For example, in the case of ${java.home}, you would have to type the path as C:\jdk1.3.0_02\jre. When this property is set to true, the policy files are portable across different platforms. This indicates that the same policy file can be used across different operating systems. This enables system administrators to store the policy file on the policy server from where it can be accessed by multiple local clients. It is always a good practice to have expandable system properties in policy files. For example, the separators used in different operating systems are automatically considered when the property is being expanded. On the other hand, if the property expansion is set to false, you have to change the separator manually depending on the operating system you want to use. A backslash (\) is used in the case of Windows systems, whereas a forward slash (/) is used in Unix systems. Therefore, the policy files in which this property is set to true are more generic and can be changed specifically depending upon the differences preventing portability.

Specifying an Additional Policy File There may be situations when you need to specify a custom policy file for a given Java application. However, in such a case, you need to set a specific property in the security properties file to true. The syntax of this property is given here: policy.allowSystemProperty=boolean

If the value of this security property is set to true, you can specify an additional policy file at the command-line prompt by using the code statement given here: java -Djava.security.manager -Djava.security.policy=niitpolicy MyApplication

The preceding code statement denotes that an additional policy file, niitpolicy, will be used along with the policy files already specified in the security properties file during the execution of the MyApplication Java application. When a double equals sign (==) is specified instead of a single equals sign (=), it indicates that only the additional policy file will be used with MyApplication. Consider the code statement given here: java -Djava.security.manager -Djava.security.policy==niitpolicy MyApplication

The same holds true for applets on using the appletviewer command. However, the command should be preceded by the -J flag, as specified here: appletviewer -J -Djava.security.policy==niitpolicy MyApplet.html


Chapter 8

Because the double equals sign (==) is specified in the preceding code statement, it indicates that the niitpolicy file will be used exclusively with MyApplet. Therefore, setting allowSystemProperty to true provides users with freedom to create their own policy file, which caters to their applications and applets. On the other hand, if allowSystemProperty is set to false, you will not be able to use custom policy files with the Java applications or applets. System administrators might set this property to false, thereby restricting users from defining their own security policies that override the system-wide policy file.

Policy Identity Scope Whenever a JAR file is encountered, the identity scope of all the trusted entities needs to be determined. The property in the security property file that allows you to do this is given here: policy.ignoreIdentityScope=boolean

If the preceding property is set to true, the identity scope for the trusted entities is ignored and the Java 2 security policy is enforced. If it is set to false, the identity scope for trusted identities is looked into. If the trusted identity is found, it is granted AllPermission.

The Keystore Type The following property of the security properties file specifies the keystore type to be used: keystore.type=jks

By default, the keystore type property is set to Java Keystore (jks), which is the proprietary keystore type of SUN Microsystems. The jks format protects the integrity of the keystore with a keystore password. The keystore can be protected from alteration through the hash value of the entire keystore. A private key in the keystore is protected by a different password. This password can also be identical to the keystore password. The private keys are generally stored in an encrypted format.

System Identity Scope The system identity scope manages a collection of certificates, keys, and trust levels. This collection is, in turn, used by applications for authentication and signing. This identity scope is specified by the system.scope property in the security properties file.

179

180

Part II


The syntax of the property is given here: system.scope=sun.security.provider.IdentityDatabase

By default, the value is set to the sun.security.provider.IdentityDatabase class. An instance of this class is created when any application or applet is executed. The system identity scope can be instantiated to any class by using the following code statement: system.scope=className

Checking Package Access Access to a package is restricted by the checkPackageAccess() method of the SecurityManager class. However, how does this method judge the packages to be restricted? This can be done by the following entry in the security properties file: package.access=string1, string2, …, stringn

The comma-separated strings represent package names that throw security exceptions when passed to the checkPackageAccess() method. However, an exception is not raised, if the associated RuntimePermission is granted. The default entry in the security properties file is as follows: package.access=sun.

The checkPackageAccess() method takes a string argument that represents a package name and throws an exception if the calling thread is not given access to the specified package. This method is used when the class loaders load classes. If the access to a restricted package is checked, the checkPermission() method is called with the permission specified here: java.lang.RuntimePermission(“accessClassInPackage.packageName”)

If RuntimePermission has not been specified, access to the package is denied and a security exception is thrown.

Checking the Package Definition By default, no packages are restricted for definition; in other words, a thread can define classes in any package. The package definition is checked by the package.definition entry in the security properties file. This entry is not set to any value and is commented out, indicating that no packages are restricted for definition. #package.definition=


Chapter 8

However, you can specify a comma-separated list of packages for this entry. These packages are passed to the SecurityManager.checkPackageDefinition() method, which throws SecurityException if the associated RuntimePermission is not specified. The checkPackageDefinition() method is called when the calling thread tries to define classes in the package specified in the argument to the method. For restricted packages, the checkpermission() method is called with the following permission argument: java.lang.RuntimePermission(“defineClassInPackage.packageName”)

The checkPackageDefinition() method is used by the loadClass() method of class loaders. However, none of the class loaders specified with the Java 2 SDK call this method because no package is restricted for definition. Let’s discuss the next security-related file, the security policy file, in the subsequent section.

The Security Policy File A Policy object represents the security policy for a Java application environment. The security policy determines the permissions available for code from different sources. In a default policy implementation, the security policy can be specified in various configuration files. You are already aware that policy files can be created by using either text editors or the policy tool. I’ve already mentioned that there are two default policy files, the system-wide policy file and a user policy file. The policy configuration files specify the permissions assigned to code from various sources. For example, any applet or application needs permissions to perform secured actions. The configuration files contain various entries, such as the keystore and grant entries, for assigning permissions to code from various sources. I’ll discuss these entries in detail in the subsequent sections.

Keystore Entries You can refer to a keystore in a policy configuration file to search for the public keys of the signers specified in the grant entries of the policy files. A keystore is a database of private keys and digital certificates that authenticate the associated public keys. If there are grant entries that specify signer aliases, a subsequent keystore entry must appear as well in the policy configuration files. There can be only a single keystore entry in a policy file. However, if multiple keystore entries are defined, only the first one is considered and the rest are ignored. The keystore entry has the following syntax: keystore “keystore_URL”, “keystore_type”;

181

182

Part II


In the preceding code statement, keystore_URL specifies the URL location of the keystore and keystore_type specifies the keystore type. If the keystore type is not specified, the type value is captured from the keystore.type property in the security properties file. The keystore URL is relative to the location where the policy file is stored. For example, consider the following URL location of the policy file, as specified in the security properties file: policy.url.3=http://www.mysite.com/policy/my.policy

Consider that the my.policy file contains the following entry: keystore “.keystore”;

In the preceding case, the keystore will be loaded from http://www.mysite.com/policy/.keystore. As seen in the preceding example, you can load a keystore from a remote location because you specified the keystore location as a URL.

Grant Entries Before executing code, it is a good practice to determine whether the code is trusted. Code always comes from a specified code source that is represented by the CodeSource object. The code source includes the URL location from where the code was downloaded and a reference to the certificates containing the public keys associated with the private keys, which are used to sign the code. The certificates are referred to by alias names from the user’s keystore. Grant entries are used to grant permissions to the codes originating from various sources. Each grant entry contains various permission entries preceded by the optional codeBase and signedBy clauses. These clauses specify the details for the code that needs to be granted permission. The syntax of a grant entry is as follows: grant signedBy “signer_names”, codeBase “URL” { permission permission_class_name “target_name”, “action”, signedBy “signer_names”; .... permission permission_class_name “target_name”, “action”, signedBy “signer_names”; };

As seen in the preceding code statements, the grant entry begins with the grant keyword and is followed by the codeBase and signedBy name-value pairs. Let’s discuss the codeBase and signedBy entries in detail in the subsequent sections.


Chapter 8

The signedBy Entry The signedBy entry is optional and can appear in any order. This entry indicates an alias name for a certificate stored in the keystore. The public key of this certificate is used to verify the digital signature on the code. Permissions are granted to the code that is signed by the private key associated with the public key in the keystore entry identified by the alias name. The signedBy entry contains a comma-separated list of multiple alias names. When multiple signers are specified, the code needs to be signed by each of them. Therefore, there is an AND relation between the multiple signers. If it were an OR relation, you would need to specify the same grant entries with the different signers multiple times. For example, consider that the signedBy clause contains “Eric, Sam, Spencer”. This indicates that the specified code is signed by Eric, Sam, and Spencer. If this entry is missing, it indicates that the permissions in the specified grant entry are valid for code that is not signed or for code that is signed by anyone.

The codeBase Entry The codeBase entry is also optional, and it specifies the location of the code source. Therefore, you grant permissions to code originating from the specified location. The codeBase value is a URL location. The meaning of the value in this entry depends on the trailing characters in the specified entry. Consider the following codeBase entry: codeBase “file:/C:/MyDocs/”

The preceding entry with a trailing / indicates that the specified permissions are granted to all the class files (and no JAR files) in the MyDocs directory. Consider the following codeBase entry: codeBase “file:/C:/MyDocs/*”

The preceding entry with a trailing /* indicates that the specified permissions are granted to all the files, both class files and JAR files, in the MyDocs directory. Consider the following codeBase entry: codeBase “file:/C:/MyDocs/-”

The preceding entry with a trailing /- indicates that the specified permissions are granted to all the files, both class files and JAR files, in the MyDocs directory and in all its sub-directories recursively.

183

184

Part II


Consider the following codeBase entry: codeBase “file:/C:/MyDocs/MyClasses.jar”

The preceding entry grants the specified permissions to only the MyClasses.jar file in the specified directory.

The permission Entries The permission entries begin with the permission keyword and specify a permission that is granted to the given code source. The syntax of a permission entry is: permission permission_class_name “target_name”, “action”, signedBy “signer_names”;

The permission_class_name keyword signifies a specific permission type, such as java.io.FilePermission or java.net.SocketPermission. The target_name field defines the target for the specified permission. For example, the file name for FilePermission is the target for the permission. The action field is not required for all types of permissions. This field is required for FilePermission; however, it is not required for RuntimePermission. For example, FilePermission has the associated actions: read, write, execute, and delete. The signedBy clause in the permission entry is optional. It indicates a signed permission. Therefore, the permission class must be signed by the entities specified after the signedBy clause to be granted the permissions. This clause is necessary for the permission classes that are not a part of the Java API and have been downloaded from a remote site. Therefore, when the remote permission class is signed by a trusted identity, it indicates that the code has been checked for authenticity. You are already aware that multiple signers can sign applets and applications and these signers are related by the AND relation. However, the permission classes can be signed by only a single entity. If multiple signers are present, only the first one is considered. Consider the following code statement: grant{ permission java.io.FilePermission “”, “write”, signed by “Duke”;};

The preceding FilePermission will be granted only if the specified Permission class is signed by the private key in the certificate specified by the Duke alias.


Chapter 8

NOTE On the Windows operating system, when you specify a file path in a string, you need to include two backslashes instead of a single one. However, this does not hold true if the file path is in a codeBase URL. The reason for this is that the java.io.Stream.Tokenizer class uses a \ as an escape string and, therefore, two backslashes are required to denote a single backslash. The tokenizer converts the double backslash into a single one when deriving the result.

Now, let’s consider certain sample entries in a policy file. Consider the following code statement: grant signedBy “Marc” { permission java.io.FilePermission “/MyDocs/MyFile.txt”, “read”; };

The preceding grant entry indicates that the read access is granted to MyFile.txt only if the code is signed by Marc. If the signedBy clause is missing, it indicates that everyone can be granted the specified permission. Consider another sample entry in the policy file: grant signedBy “Marc”, codeBase “file:/home/MyDocs/*” { permission java.security.SecurityPermission “security.insertProvider.*”; };

The preceding entry specifies that if the code is loaded from a signed JAR file that is located in the home/MyDocs directory on the local file system and the public key is referenced by the alias name “Marc” in the keystore, the code can add providers using the insertProvider() method. Now, I’ll discuss the last security file, cacerts.

The cacerts File The cacerts file is also called the Certificates KeyStore file. It represents a systemwide keystore with Certification Authority (CA) certificates. The cacerts file can be

185

186

Part II


managed and modified by system administrators by using the keytool command. However, the keystore type must be the default JKS format. The cacerts file is located in the java.home\lib\security\ directory. It contains five VeriSign root CA certificates. These certificates can be listed by using the keytool command, as given here: keytool -list -keystore cacerts

When you execute the preceding command, you will be prompted for a password. The default password is changeit. You should change this password because the keystore contains trusted CA certificates that should not be tampered with.

Java 2 Security APIs In addition to the files discussed in the preceding sections, Java 2 also provides certain security packages that help in building secure Java applications. Java 2 provides two new subpackages, java.security.cert and java.security.spec, in addition to the package, java.security, and its subpackages, java.security.acl and java.security.interfaces, which were there in jdk1.1. Java 2 introduced two new subpackages, java.security.cert and java.security.spec. These packages form the Java Cryptographic Architecture ( JCA). JCA provides Java programs with cryptographic capabilities. Let’s discuss these packages in detail in the subsequent sections.

The java.security Package This security package includes all the classes and interfaces needed by the security framework in Java 2. Most of the classes and interfaces supported by this package are abstract and provider-based. The classes included in this package mainly represent keys, keystores, signatures, access control, and permissions. Let’s discuss the components of this package in detail in the subsequent sections.

The GuardedObject Class and Guard Interface An object created by the Guard interface is used to guard a protected resource. Consider a scenario where the supplier of a resource is not in the same thread as the consumer of that particular resource. In this scenario, the consumer thread cannot provide the access control context information to the supplier thread due to security reasons. Therefore, in Java 2, the GuardedObject class protects access to the specified resource.


Chapter 8

First, I’ll explain how the supplier of a resource uses the GuardedObject class to provide information to the consumer of a resource. The supplier of a resource creates an object that represents the resource, and then it creates GuardedObject that encapsulates this resource object, and finally provides GuardedObject to the consumer of the specified resource. While creating GuardedObject, the supplier also creates a Guard object and specifies certain security checks within it. Therefore, the consumer or anyone can obtain the resource object only if these security checks are satisfied. Guard is an interface, and objects can be created based on this interface. This interface contains a single method, checkGuard(). This method takes an Object parameter and performs certain security checks. Let’s consider an example to explain the use of the GuardedObject class and Guard interface. Consider that a thread is requested for read access to MyFile.txt. However, the thread has no knowledge of the requestor. Therefore, access control checking can be delayed by using the following code statements: FileInputStream fis = new FileInputStream(“MyFile.txt”); FilePermission perm = new FilePermission(“MyFile.txt”, “read”); GuardedObject go = new GuardedObject(fis, perm);

The thread passes the go object to the consumer thread (the requestor). For the requestor to obtain the access to the file, it needs to specify the following code statement: FileInputStream fis = (FileInputStream) go.getObject();

The getObject() method invokes the checkGuard() method on the Guard object, perm. This is so because the java.security.Permission class implements the Guard interface. Therefore, a proper access control check takes place when the requestor is granted the specified resource access. The implementation of the GuardedObject class and the Guard interface is very general. Therefore, developers can easily extend these classes and interfaces to create the appropriate access control tools.

The Provider Class This class is also a part of the java.security package. The phrase, cryptographic service provider, is used interchangeably with the term, provider. Providers refer to a set of packages that provide an implementation of cryptographic aspects in the Java 2 SDK. The Provider class is an interface for such packages. This class contains methods that provide access to the provider name, the version number, and additional information about providers.

187

188

Part II


To provide implementation of cryptographic services, developers write the implementation code and create a subclass of the Provider class. The Java 2 security API needs to know the various services implemented by a provider. The subclass constructor sets the values of various properties that are used by the Java 2 security API to solve its purpose. Various types of services are provided by several provider packages. However, these services can differ in their implementation and features. Certain implementations may be software-based, whereas others may be hardware-based. They can also differ in their platform-independence. The Java Cryptography Architecture ( JCA) allows both users and developers to decide on cryptographic implementations depending upon their requirements. For each engine class in the Java API, a particular implementation is requested and instantiated. This is done by calling the getInstance() method on the engine class and passing to the method the name of the appropriate algorithm and the name of the provider whose implementation is needed. In the case where no provider is specified, the getInstance() method searches among the registered providers to locate an implementation of the requested service specified by the named algorithm. In Java, providers are installed by order of preference. This order matches the order in which these providers are searched for when no provider is specified. The provider argument is specified in the getInstance() method for developers who wish to specify the provider from which they want an algorithm. The getProviders() method of the Security class provides a list of all the installed providers. Therefore, a program can use this method to choose a provider from a given list. Let’s observe the process of installing providers.

Installing Providers For installing a provider, there are two phases, namely installing the provider package classes and configuring the provider. In turn, there are several ways of installing the provider package classes. These are listed here: ◆ You can install a provider class package by placing the ZIP file or the JAR file containing the class files anywhere on the CLASSPATH. ◆ You can install your provider JAR file as an installed or bundled extension in

the extensions directory.


Chapter 8

Once you have installed the provider classes, you need to configure the provider by adding it to your list of approved providers. You can do this by editing the java.security file in the java.home/lib/security directory. Consider the code statement given here: security.provider.n=masterClassName

The preceding code statement specifies a type of property that you can set in the java.security file. This statement declares a provider and sets its precedence order as n. The provider’s master class is specified by masterClassName. This class is specified in the provider’s documentation. The master class is a subclass of the Provider class. You can also dynamically register providers by calling the addProvider() or insertProviderAt() method of the Security class. However, this type of dynamic registration is possible only by trusted programs.

NOTE The addProvider() method adds a provider at the end of the list of installed providers. On the other hand, the insertProviderAt() method adds a new provider at a specified position in the array of providers. As a result of this, all the providers after the inserted provider are shifted up one position. Both these methods return the preference position in which the provider was added to the list. A provider cannot be added if it is already installed. Therefore, in such cases, a –1 preference value is returned by these methods, indicating that the specified provider is already there in the list.

To change the preference position of a provider, you first need to remove the provider from the list and then add it again at the new position. To remove a provider, you need to call the removeProvider() method, which is defined here: public void removeProvider(String name)

The preceding method removes the provider specified by the string name. If the specified provider is not installed, the method returns silently without raising any exception. When the specified provider is removed, the providers following it are shifted down one position towards the starting of the list of installed providers.

The Security Class The Security class manages the installed providers and security-wide properties. This class is never instantiated and contains only static methods. Note that the meth-

189

190

Part II


ods for adding or removing providers and those for setting the security properties can be invoked only by trusted programs. However, for code to be designated as trusted, it needs to be granted permissions for a particular action. Therefore, the permission required for adding a provider or inserting it at a specified position in the list is as follows: permission java.security.SecurityPermission “insertProvider.name”;

For removing a provider, the permission needed in the policy file is as follows: permission java.security.SecurityPermission “removeProvider.name”;

The Security class performs the following functions: ◆ Manages providers ◆ Sets the security properties

The various methods defined in the Security class for performing the preceding functions are listed here: ◆ getProviders() ◆ getProvider() ◆ addProvider() ◆ insertProviderAt() ◆ removeProvider() ◆ getProperty() ◆ setProperty()

A few of the preceding methods have already been discussed in a preceding section. I’ll discuss the remaining ones in the subsequent sections.

The getProviders() and getProvider() Methods These methods are used to query which providers are already installed. The syntax of the getProviders() method is as specified here: public Provider[] getProviders()

This method returns an array containing all the installed providers. The providers are ordered as per their preference order in the array. The syntax of the getProvider() method is as specified here: public Provider getProvider(String providerName)


Chapter 8

This method returns the provider identified by providerName. The method returns null if the specified provider is not found.

The getProperty() and setProperty() Methods You are already aware that the Security class contains a list of system-wide security properties. These properties can be set and accessed by the setProperty() and getProperty() methods respectively. However, only the trusted programs can invoke these methods. The syntax of these methods is given here: public static String getProperty(String key) public static void setProperty(String key, String datum)

Keystore Management The java.security package provides interfaces and classes for key generation and management. In this section, I’ll discuss these classes and their use. The java.security package contains classes such as KeyFactory and KeyFactorySpi. The KeyFactory class is used to convert keys into key specifications. The reverse also holds true. The KeyFactorySpi class defines the Service Provider Interface (SPI) for the KeyFactory class.

NOTE Key factories allow you to create key objects from the given key specifications. On the other hand, they also allow you to derive key specifications from the present key objects. Therefore, key factories can be termed as bi-directional.

You can create a KeyFactory object by invoking the KeyFactory.getInstance() method. You can generate keys from a key specification by using the generatePublic() and generatePrivate() methods. To derive the key specification from a KeyFactory object, you can invoke the getKeySpec() method. The security package also provides a KeyPair class, which holds both the private and public keys. This class contains the getPrivate() and getPublic() methods, which return the private and public keys respectively. The KeyStore class contains interfaces to access and edit the information stored in a keystore. This class contains an in-memory collection of keys and certificates. The KeyStoreSpi defines the SPI for the KeyStore class. You can create an object of the

191

192

Part II


KeyStore class by calling the getInstance() static method on the KeyStore class.

The syntax of this method is specified here: public static KeyStore getInstance(String type)

However, before using the KeyStore object, the actual keystore data needs to be loaded into the memory by calling the load() method. The definition of the load() method is specified here: public final void load(InputStream stream, char[] password)

The password passed to this method is optional, and it is used to check the integrity of the keystore data. Therefore, if this parameter is not provided, the keystore data is not checked for integrity. All the keystore entries are accessed with the help of unique aliases. The aliases() method returns a list of all the alias names in the keystore. The getKey() method returns the key associated with the given alias name. The deleteEntry() method deletes an entry associated with a given alias name. Finally, the inmemory keystore is saved by the store() method. The java.security package also contains a KeyPairGenerator class. This class is used to generate key pairs. The KeyPairGeneratorSpi class defines the SPI for this class. A KeyPairGenerator object is created by using the static getInstance() method of the KeyPairGenerator class. However, the object must be initialized before it can generate keys. There are four types of initialize() methods to perform this task. All of them have the same name, initialize, with a different signature. These initialize() methods allow you to generate key pairs either in an algorithmspecific or an algorithm-independent manner. These methods allow you to provide a source of randomness. They generally use the SecureRandom implementation of the highest-priority provider as this source.

The SignedObject Class This class is used for creating runtime objects whose integrity cannot be compromised. This class contains another Serializable object, the yet-to-be signed object and its signature. The signed object is a copy of the original object. After the copy is created, any modifications in the original object do not have any effect on the copy. Therefore, a signed object is permanent. Consider the following code statements: Signature sign = Signature.getInstance(algorithm,provider); SignedObject so = new SignedObject(myObject, signKey, sign);


Chapter 8

NOTE The Signature class provides digital signature functionality to Java applications. The Signature object is used to generate and verify digital signatures. The signature algorithm object can be requested by providing either the algorithm name or both the algorithm and provider name. You’ll read more about the Signature class in Chapter 11, “Message Digests and Digital Signatures”.

The preceding statements create a signed object. Once you have received the signed object, you need to verify the same. You can do this by executing the following code statements: String algorithm = so.getAlgorithm(); Signature verifySign = Signature.getInstance(algorithm, provider); so.verify(verifySign);

There are many applications in which the SignedObject class can be used. It can be used by any Java application as an authorization token. This token can be passed around without being maliciously modified. This object can also be used to sign and serialize data for storage outside the Java runtime environment. Nested signed objects can be used to create a sequence of signatures that resemble a chain of authorization and delegation. The various permission classes discussed in a previous chapter are also part of the java.security package. The security package also provides APIs for message digests

and digital signatures. These will be discussed in Chapter 11, “Message Digests and Digital Signatures”.

The CodeSource Class This class specifies the code base that includes the URL location of the code and the certificates used to verify the signed code originating from this location. The code base is represented as a java.net.URL object and a list of signers, which is an array of java.security.cert.Certificate objects. Following is the constructor of this class: CodeSource(URL url, Certificate[] certs)

This class has the getLocation() method, which extracts the URL location, and the getCertificates() method, which locates the certificates. In addition to these

193

194

Part II


methods, the CodeSource class also provides an implies() method, which returns whether the CodeSource object specified as an argument is implied by this CodeSource object.

The Principal Interface The java.security package includes this interface to represent the principals that denote entities, either independent users or companies. It is used to grant access to a specified resource. In Java 2, there is no implementation for this interface. A group of principals is denoted by the Group interface of the java.security.acl package. This package is discussed in a subsequent section.

The ProtectionDomain Class This class is used to represent a unit of protection within the Java application environment. The arguments to its constructor are a CodeSource object and a PermissionCollection object, which represent the set of permissions granted to the CodeSource object. ProtectionDomain(CodeSource codesource, PermissionCollection permissions)

This class contains the getCodeSource() method, which returns the code source of the domain. The getPermissions() method returns the permissions of the domain. It also contains an implies() method, which checks whether the specified protection domain implies the permission specified in the Permission object.

NOTE Classes that have the same permissions but are from different code sources belong to different protection domains. Each class belongs to only one protection domain. However, this depends on its code source and the permissions granted to the code source. All the classes from the same code source belong to the same protection domain.

The Policy Class The java.security package provides the Policy class, which represents the systemwide security policy for a Java application environment. This class specifies the permissions available for code from various sources. There is only a single Policy object


Chapter 8

in effect, which is consulted by the ProtectionDomain class while initializing permissions. The policy information contained in the Policy object comes from the policy implementation. The getPolicy() method of this class returns the currently installed Policy object. This can be changed by invoking the setPolicy() method. The refresh() method reloads the current configuration of the Policy object. The getPermissions() method takes a CodeSource object as a parameter. This method evaluates the global policy and returns a Permissions object that contains the set of permissions allowed for the code from the specified code source.

The AlgorithmParameters Class This class is an engine class that provides an opaque representation of cryptographic parameters. This indicates that no direct access is allowed to the parameter fields. The only information derived is the name of the algorithm associated with the parameter set and the encoding for this parameter set. The getParameterSpec() method converts an AlgorithmParameters object to a transparent specification where you can access values from the parameter fields. The java.security package also includes the AlgorithmParameterGenerator class, which is used to generate a set of parameters to be used with a specific algorithm. The package also includes the AlgorithmParameterGeneratorSpi class, which defines the SPI for the AlgorithmParameterGenerator class.

The java.security.spec Package This package defines the classes and interfaces for key and algorithm parameter specifications. The key specifications are transparent representations of the key material that constitutes a key. This indicates that you can access the key material value through one of the get() methods defined in the associated specification class. This package contains the key specifications for the DSA public and private keys, RSA public and private keys, X.509 public and private keys in DER-encoded format, and PKCS#8 private keys in the DER-encoded format. This package also includes an algorithm parameter specification class, DSAParameterSpec, which specifies the set of parameters used with the DSA algorithm. This package provides two interfaces, AlgorithmParameterSpec and KeySpec. The AlgorithmParameterSpec interface is a specification of cryptographic parameters. The KeySpec interface is a specification of the key material that is contained in a cryptographic key. This interface also groups all the key specifications. Both these interfaces do not contain any methods or constants.

195

196

Part II


The java.security.cert Package This package contains classes for managing digital certificates and certificate revocation lists (CRLs). It also provides classes for managing X.509 certificates and CRLs. The package contains the Certificate class, which is used to manage different types of identity certificates. The X509Certificate class extends the Certificate class and implements the X509Extension interface. This class is specifically for X.509 certificates. The CRL class is an abstraction of CRLs that have different formats with certain common uses. The CertificateFactory class generates certificates and CRL objects from their encodings. The CertificateFactorySpi class is used to define the SPI for the CertificateFactory class. CertificateFactory objects can be created by using the getInstance() method. The generateCRL() and generateCertificate() methods are used to create a CRL object and a certificate, respectively.

The java.security.interfaces Package This package is so named because it only contains interfaces that are used for generating the Digital Signature Algorithm (DSA) and Rivest, Shamir, and Adleman AsymmetricCipher Algorithm (RSA) keys. It generates the RSA keys as defined in the RSA Laboratory Technical Note PKCS#1 and the DSA keys as defined in NIST’s FIPS-186. DSAKey, DSAPrivateKey, and DSAPublicKey are interfaces to the DSA keys. This package also includes the DSAKeyPairGenerator interface for generating DSA key pairs. The DSAParams interface defines a DSA key family. The RSAKey, RSAPrivateKey, and RSAPublicKey interfaces are meant for RSA keys. The RSAPrivateCrtKey interface is an interface for private RSA keys. This interface follows the PKCS#1 standard and uses the Chinese Remainder Theorem (CRT) information values.

The java.security.acl Package This package includes interfaces for managing access control lists (ACLs). The classes and interfaces in this package have been superseded by the classes in the java.security package. The interfaces included in this package are as follows. The Acl interface represents an ACL. The AclEntry interface is used for denoting a single entry in an ACL. The Group interface is used to represent a group of principals. The Owner interface is used to manage the owners of ACLs or ACL configurations. Finally, the Permission interface represents a permission used to grant access to a specified resource.


Chapter 8

Summary In this chapter, I discussed the security files in Java 2. These are the java.security, security policy, and cacerts files. I explained the entries in these files in detail. Then, I discussed the security packages in Java 2. These include the java.security, java.security.spec, java.security.cert, java.security.interfaces, and java.security.acl packages. Next, I talked about the java.security package extensively. Finally, I discussed the classes and interfaces contained in this package.

Check Your Understanding Multiple Choice Questions 1. There are two providers installed in a JVM, P1 and P2. P1 implements SHA1withDSA, SHA, and MD5. P2 implements SHA1withDSA, MD5withRSA, MD2withRSA, MD2, and MD5. P1 has preference order 1 and P2 has preference order 2. If you are looking for an MD5withRSA signature algorithm, which of the providers will be chosen? a. P1

c. P1 and P2

b. P2

d An error will occur

2. What does the following code statement denote? java -Djava.security.manager -Djava.security.policy= =ibmpolicy SecureApplication

a. The ibmpolicy file is used along with the other policy files specified while executing the Java application. b. Only the ibmpolicy file is used while executing the Java application. c. The ibmpolicy file is used along with the other policy files specified while executing the Java applet. d. Only the ibmpolicy file is used while executing the Java applet. 3. What does the following entry denote? codeBase “file:/C:/JavaDocs/*”

a. Permissions are granted to only the class files in the JavaDocs directory. b. Permissions are granted to all the files, both class and JAR files, in the JavaDocs directory.

197

198

Part II


c. Permissions are granted to all the files, both class and JAR files, in the JavaDocs directory and all its subdirectories, recursively. d. Permissions are granted to all files on the hard drive. 4. I need to change the preference position of a provider to an intermediate position in the list. Which of the following provider methods should I choose? a. addProvider() b. insertProviderAt() c. removeProvider() d. getProviders() 5. Which is the package in which the classes and interfaces have been superseded by the classes in the java.security package? a. java.security.spec b. java.security.cert c. java.security.interfaces d. java.security.acl

Short Questions 1. Explain the steps for installing providers. 2. When do you need the GuardedObject class and the Guard interface?

Answers Multiple Choice Answers 1. b. P1 is first searched for the desired implementation. No implementation is found, so P2 is searched. The implementation is found in P2; therefore, it is returned. 2. b. When a double equals sign (==) is specified instead of a single equals sign (=), it indicates that only the additional policy file will be used with the specified application. 3. b. A codeBase entry with a trailing /* indicates that the specified permissions are granted to all the files, both class and JAR files, in the given directory.


Chapter 8

4. b and c. To change the preference position of a provider, you first need to remove the provider from the list and then add it at the new position. The removeProvider() method is used to remove the provider from the list, and the insertProviderAt() method is used to insert the provider at the specified position in the list. 5. d. The classes and interfaces in the java.security.acl package have been superseded by the classes in the java.security package.

Short Answers 1. For installing a provider, there are two phases—installing the provider package classes and configuring the provider. You can install a provider class package by placing the ZIP file or the JAR file containing the class files anywhere on the CLASSPATH. You can install your provider JAR file as an installed or bundled extension in the extensions directory. Once you have installed the provider classes, you need to configure the provider by adding the specified provider to your list of approved providers. You can do this by editing the java.security file in the java.home/lib/security directory. To add a provider statically, use the security.provider.n=masterClassName entry. You can also dynamically register providers by calling the addProvider() or insertProviderAt() method of the Security class. However, this type of dynamic registration is possible only by trusted programs. 2. When the supplier of a resource is not in the same thread as the consumer of that resource, the consumer thread cannot provide the access control context information to the supplier thread due to security reasons. Therefore, in Java 2, the GuardedObject class protects access to the specified resource. The supplier of a resource creates an object that represents the resource, and then it creates GuardedObject, which encapsulates this resource object, and finally it provides GuardedObject to the consumer of the specified resource. While creating GuardedObject, the supplier also creates a Guard object and specifies certain security checks within it. Therefore, the consumer or anyone can obtain the resource object only if these security checks are satisfied. Guard is an interface, and objects can be created based on this interface. This interface contains a single method, checkGuard(). This method takes an Object parameter and performs certain security checks.

199


Chapter 9 An Introduction to Java 2 Security Tools

I

n Chapter 2, “Java Security Model”, I discussed the four security-related tools supported by the new Java security model. These include keytool, the jar commandline tool, the jarsigner command-line tool, and the policy tool. I discussed that keytool is used for key and certificate management. The jar command-line tool is used to compress and archive Java class files into JAR files. The jarsigner tool is used to sign and verify the JAR files created by the jar tool. Finally, the policy tool is used for creating and managing policy files, which contain permissions for accessing system resources. In this chapter, I’ll discuss the functions of these tools in more detail.

The keytool Command The keytool command is basically used to manage keystores. Using keytool, you can create key pairs and sign certificates, export the signed code along with the certificates, and import certificates to verify the signatures attached with the code. You can also issue certificate signing requests (CSRs) for signing code. These requests are sent to the certification authorities (CAs) for signing.

NOTE Keystores have two types of entries, key entries and trusted certificate entries. Key entries contain sensitive cryptographic key information. This information is stored in a secure format to protect it from unauthorized access. Therefore, such a key entry typically stores a private key along with its associated certificate chain for the corresponding public key. The jarsigner and keytool commands operate on only private key entries with their associated certificate chains. On the other hand, the trusted certificate entries contain a single public key certificate belonging to a secondary entity. However, the keystore owner trusts that the public key in this certificate actually belongs to the person who signs this certificate.

The syntax for using the keytool command is as follows: keytool [command]

AN INTRODUCTION TO JAVA 2 SECURITY TOOLS

Chapter 9

When you enter this command at the command prompt, you get the output as shown here: C:\>keytool command keytool usage:

-certreq

[-v] [-alias ] [-sigalg <sigalg>] [-file ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-delete

[-v] -alias [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-export

[-v] [-rfc] [-alias ] [-file ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-genkey

[-v] [-alias ] [-keyalg ] [-keysize ] [-sigalg <sigalg>] [-dname ] [-validity ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-help

-identitydb

[-v] [-file ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-import

[-v] [-noprompt] [-trustcacerts] [-alias ] [-file ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

203

204

Part II


-keyclone

[-v] [-alias ] -dest <dest_alias> [-keypass ] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-keypasswd

[-v] [-alias ] [-keypass ] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-list

[-v | -rfc] [-alias ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-printcert

[-v] [-file ]

-selfcert

[-v] [-alias ] [-sigalg <sigalg>] [-dname ] [-validity ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

-storepasswd [-v] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

Therefore, as seen in the preceding output, there are many commands and options associated with keytool. Let’s discuss these options in detail.

The keytool Options The command keyword used with the keytool command can be replaced by a number of options. I’ll discuss the options in the sequence in which they appear on the screen. First, let’s discuss certain features common to all these options. All the options are preceded with a minus (-) sign. The options can be specified in any order. Brackets surrounding any option indicate that the user will be prompted for the values, if they are not provided at the command line. There are certain options that appear for many commands. These are listed here: ◆ The -v option indicates that the command will display a verbose or detailed

output.


Chapter 9

◆ The -storetype option specifies the type of keystore to be used in the specified command. The default keystore type is returned by the getDefaultType() method in the java.security.KeyStore class as indicated by the keystore.type property. ◆ The -storepass option specifies the password used to protect the keystore.

If this option is not specified at the command line, the user is prompted for it. This option is generally provided for all commands that access the keystore. ◆ The -keystore option specifies the location of the keystore. The default keystore location is the .keystore file stored in the user’s home directory.

Now, I’ll discuss the various options in detail.

The –certreq Option -certreq

[-v] [-alias ] [-sigalg <sigalg>] [-file ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

The keyword in bold represents the options of the keytool command. This option is used to generate a CSR, which is in the PKCS#10 format and is sent to a CA.

NOTE PKCS stands for Public-Key Cryptography Standards. PKCS#10 format is the certification request syntax standard. This standard describes the syntax for a certification request, which consists of a public key, a distinguished name, and a set of attributes. All of these are signed by the entity requesting certification. The reason for including a set of attributes is to provide additional information about a given entity. For example, the postal address for an entity can be included. If electronic mail is not functioning, the signed certificate can be returned to the postal address.

The private key and the X.500 name associated with the alias of the certificate are used to generate this request in the specified format. The CA authenticates the requestor and returns a certificate or chain of certificates. This certificate is used to replace the self-signed certificate in the keystore. Private keys are protected by a password. Therefore, to access these keys, you need to specify the associated password. The user is prompted for the password in two cases, when the –keypass

205

206

Part II


option is not provided and when the key password is different from the keystore password. The CSR is signed as per the algorithm specified by the sigalg option and stored in the csr_file. If the file is not specified, the CSR is sent to the standard output device.

The –delete Option -delete

[-v] -alias [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option deletes the entry identified by the alias keyword from the keystore. If an alias is not provided at the command line, the user is prompted for it.

The –export Option -export

[-v] [-rfc] [-alias ] [-file ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option accesses the keystore and reads the certificate specified by the alias option and stores it in the file, cert_file. If the –rfc option is specified, the certificate is provided in the Base 64 format; otherwise, it is provided in the binary encoding format. If alias points to a trusted certificate, the specified certificate is returned. Otherwise, alias points to a key entry in a certificate chain and the first certificate in the chain is returned. This certificate authenticates the public key of the entity addressed by alias.

The –genkey Option -genkey

[-v] [-alias ] [-keyalg ] [-keysize ] [-sigalg <sigalg>] [-dname ] [-validity ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option generates a key pair that constitutes the public key and its associated private key. It wraps the public key into an X.509 v1 self-signed certificate and stores it as a single-element certificate chain. This chain and the private key associated with it are stored in a new keystore entry identified by the alias keyword.


Chapter 9

NOTE The X.509 standard outlines the information that needs to go into a certificate. It also describes the format of the data that goes into a certificate. All X.509 certificates contain the version, serial number, signature algorithm identifier, issuer name, validity period, subject name, and subject public key information in addition to the signature. There are three versions defined for these certificates namely, v1, v2, and v3.

The keyalg keyword identifies the algorithm used to generate the key pair. The keysize keyword specifies the size of the keys to be generated. The sigalg keyword specifies the algorithm to sign the self-signed certificate. The algorithm specified by the sigalg keyword should be compatible with that specified by the keyalg keyword. The dname keyword specifies the X.500 distinguished name to be related to the alias keyword. This name is used in the Issuer and Subject fields of the self-signed certificate. The valDays keyword specifies the validity period for which the specified certificate would be valid. The keypass keyword is used to specify the password for the private key in the key pair. If this keyword does not specify a password, the user is prompted for the password. The password should be at least six characters in length. If the user presses the Enter key instead of typing the password, the keystore password is used as the password for the primary key.

The -help Option This option provides help on the use of the keytool command. It lists all the commands and options supported by the command.

The -identitydb Option -identitydb

[-v] [-file ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option reads the JDK 1.1.x-style identity database represented by the file, idb_file. After reading, it adds its entries to the keystore. If a file is not specified with the command, the identity database is read from the standard input device. If the keystore does not exist, it is created when the command is executed. Only the database entries that are marked as trusted are imported to the keystore, and a keystore entry is created. The identity entry’s name is used as the alias name for the keystore entry. All the untrusted entries are ignored. The private keys from the database entries are encrypted by the password represented by the storepass keyword.

207

208

Part II


This same password protects the keystore as well. However, you can assign different passwords to the private keys by using the keytool command. An identity entry in the identity database can have multiple certificates for the same public key. However, a keystore entry for a private key includes the key and a certificate chain where the first certificate of the chain is the public key associated with the specified private key.

The -import Option -import

[-v] [-noprompt] [-trustcacerts] [-alias ] [-file ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option reads the certificate or certificate chain and stores it in the keystore entry identified by the alias keyword. The certificate or certificate chain is provided from cert_file. If the file is not provided, the certificate is read from the standard input. The keytool command can import X.509 v1, v2, and v3 certificates, and the PKCS#7 format certificate chains consisting of such types of certificates. The data that is to be imported has to be provided in either Base 64 or binary encoding format.

NOTE The PKCS#7 format stands for the cryptographic message syntax standard. This standard describes the general syntax for data that has cryptography techniques applied to it. Examples of cryptography techniques are digital signatures and digital envelopes.

When you are importing a new trusted certificate, make sure that the alias does not already exist in the keystore. The keytool command verifies this certificate by attempting to add it to the certificate chain containing trusted certificates. If the trustcacerts option is specified, additional certificates are considered for constructing the chain of trust. These certificates are specified in the cacerts file. The cacerts file contains a system-wide keystore of CA certificates. This file is present in the java.home\lib\security directory. The cacerts file can be configured and managed by using keytool and specifying jks as the default keystore type. The default password provided to this file is changeit. This password should be changed along with the file’s default access permissions when you install JDK.


Chapter 9

If the keytool command fails to build a trust path from the certificate that needs to be imported up to a self-signed certificate, the certificate information is printed. The user needs to verify this information for validity before importing it as a trusted certificate. The user can validate this information by matching the displayed certificate fingerprints with the expected ones. It is confirmed that the original certificate has not been replaced during transit if the fingerprints match. To avoid marking a JAR file with malicious applets as trusted, it is important to verify the certificate before importing it. However, if the -noprompt option is specified, the user will not be prompted for verification. On the other hand, if a certificate reply is imported, it needs to be validated by using trusted certificates from the keystore or the cacerts file. However, keytool validates the reply differently, depending on whether the reply is a certificate or a certificate chain. If the reply is a single X.509 certificate, the keytool command tries to build a trust chain starting from this reply until a self-signed trusted certificate. Therefore, this certificate reply and the related certificates are used to form a new certificate chain with the specified alias. On the other hand, if the reply is a PKCS#7 certificate chain, the chain is arranged before the keytool command validates it. The chain is arranged starting with the user certificate and ending with the self-signed root CA certificate. The keytool command tries to match the root CA certificate with the trusted certificates available in the keystore or the cacerts file. If keytool is unable to find a match, the root CA certificate information is printed. The user can verify this information by matching the fingerprints. If the -noprompt option is provided, there is no interaction with the user. The new certificate chain thus formed replaces the old certificate chain for the specified entry. If a valid keypass is provided, the new chain can also replace the old chain. If the password is not provided and is different from the keystore, the user is prompted for it.

The -keyclone Option -keyclone

[-v] [-alias ] -dest <dest_alias> [-keypass ] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option is used to create multiple certificate chains for a given key pair. This option can be used for backup purposes. As the name suggests, it is used to create a clone of an already existing keystore entry.

209

210

Part II


This option creates a new keystore entry that has the same private key and certificate chain as the original entry. The original entry is marked by the alias keyword, whereas the new entry is identified by the dest_alias keyword. If the destination alias is not specified, the user is prompted for it. You are already aware that the private key is protected by a password, which is specified by the keypass keyword. Therefore, an entry is cloned only if the user provides the valid keypass. The user is prompted for this password only if the password is different from that of the keystore or keypass is not specified. Can I specify a different private key password for the new keystore entry? Yes, you can do this in two ways. One way is to specify the new_keypass value with the -new option. Another way is not to specify the -new option. In the latter case, the user is prompted to specify a password for the new entry. If the user does not enter any password, the password for the original entry is applied to the new entry as well.

The -keypasswd Option -keypasswd

[-v] [-alias ] [-keypass ] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option is used to change the old password identified by the old_keypass keyword to the new password identified by the new_keypass keyword. The user is prompted for the password in two cases, when the -keypass and -new options are not specified and when the password for the private key is different from that of the keystore password.

The -list Option -list

[-v | -rfc] [-alias ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option is used to display the contents of the keystore entry marked with the alias name. In case the -alias option is not specified, the entire keystore entries are printed. The option displays the contents on the standard output device. As seen in the preceding code, either the -v or -rfc option needs to be provided at a time. Both these options cannot be specified together. Let’s first understand the difference between the two options. The -v option prints the certificate in human-readable format. Information such as the owner, issuer, and the serial number is also printed with this option. On the other hand, the -rfc option prints the certificate contents using the printable encoding format.


Chapter 9

The -printcert Option -printcert

[-v] [-file ]

This option is different from the -list option in that it can be used without a keystore specification. The option reads the certificate from the file specified by the cert_file keyword. If the -file option is not specified, the certificate is read from the standard input device. The certificate is displayed in human-readable format.

The -selfcert Option -selfcert

[-v] [-alias ] [-sigalg <sigalg>] [-dname ] [-validity ] [-keypass ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option is used to generate a X.509 v1 self-signed certificate. It does this by using keystore information, namely the public and private keys associated with the specified alias name identified by the alias entry. If the -dname option is specified at the command line, dname is used as the distinguished name both for the issuer and subject of the certificate entry. The -validity option specifies the validity limit for the new certificate in the number of days. The new certificate is stored as a single-element certificate chain in the keystore entry identified by the alias name. Therefore, this new certificate replaces the existing certificate chain. The -sigalg <sigalg> option specifies the algorithm to be used to sign the newly generated certificate. The private key is protected by the password specified by the keypass keyword. If keypass is not specified and the private key password is different from that of the keystore password, the user is prompted for the password.

The -storepasswd Option -storepasswd [-v] [-new ] [-keystore ] [-storepass <storepass>] [-storetype <storetype>] [-provider <provider_class_name>] ...

This option is used to specify a new password for the keystore identified by the -keystore option. The new password is identified by the new_storepass keyword. The password should be at least six characters long. Now that I’ve discussed all the options of the keytool command, let’s discuss the use of this command.

211

212

Part II


Use of the keytool Command I’ll emphasize the use of the keytool command in this section. Imagine that you have to create a keystore for managing your public/private key pairs. The keystore will also manage the trusted certificates. Therefore, the first step that you need to take is to create a keystore and generate a key pair.

Create a Keystore and Generate a Key Pair To create a keystore and to generate a key pair, specify the following command at the command prompt: keytool -genkey -keystore myStore -alias trialKey

The preceding command requires you to enter certain information, which is illustrated in Figure 9-1. The preceding command creates a keystore named myStore. Because the location of the keystore is not defined in the command, the default directory from where the command is executed is the location of myStore. In the preceding example, C: is the location where the keystore is located after the execution of the command. The password, awe345, is assigned to the keystore. The preceding command also generates the public/private key pair with the alias, trialKey, for the entity defined by the common name of Caryl Johnson. The other details of this entity, such as the organizational unit or organization, are also defined. The private key of this pair is assigned the password, ret345.

FIGURE 9-1 Using the keytool command with the -genkey option


Chapter 9

The preceding command generates a self-signed certificate, which includes the public key and the distinguished name information. Because the validity limit is not specified in the preceding command, the default limit of 90 days is assigned to the certificate. I’ve discussed keytool and its options in the preceding section. I’ll now discuss the jar tool.

The jar Tool The main function of the jar tool is to store multiple files in a single Java ARchive ( JAR) file. The jar tool is a compression and archiving tool. It is based on the ZIP compression format. You can use the jar tool for zipping files so that tasks such as data compression, archiving, unpacking, and decompression can be performed on the resultant JAR files. You are already aware that the components of applets and applications can be stored together in a JAR file. This improves the download time because the browser can download the entire application or applet with all its components in a single HTTP transaction. If it were not for JAR files, it would take many transactions to download an entire application or applet with all its components. Using the jar tool, you can perform certain basic operations on JAR files. These operations are: ◆ Creating JAR files ◆ Viewing the contents of JAR files ◆ Extracting the contents of JAR files ◆ Updating JAR files ◆ Invoking the applets packaged in a JAR file ◆ Running an application packaged as a JAR file

Let’s discuss the use of the jar tool in the preceding operations.

Creating JAR Files The syntax for using the jar command to create JAR files is specified here: jar cf [jar-file] [input-file(s)]

I’ll now explain the meaning of all the options, which the jar command-line tool uses while creating JAR files. The various options and their descriptions are listed in Table 9-1.

213

214

Part II


Table 9-1 Options Supported by the jar Command Option

Description

c

Creates a JAR file.

f

Directs the output to a JAR file instead of stdout.

v

Produces a verbose output on stdout.

0

Stores the files in a JAR file without compressing them.

M

Indicates that the default manifest file is not needed.

m

Includes manifest information from an existing manifest file.

C

Changes the directories during the execution of a program.

I’ll consider an example to explain the use of the jar tool during the creation of JAR files. For example, all the class files in the current directory need to be added to a JAR file. The command for this task is as follows: jar cvf classes.jar *.class

In the preceding example, all the class files in the current directory are stored in the classes.jar file. A manifest file is automatically created by the preceding command and is the first entry in the JAR file. The name of this manifest file is manifest.mf by default.

NOTE All meta-information for an archive is stored in the manifest file. The manifest file contains a list of files present in the archive. Basically, the files to be signed need to be included in the manifest file. For more information on the manifest file, you can visit http://java.sun.com/products/jdk/1.2/docs/guide/jar/manifest.html.

You are aware that the v option with the jar command produces a verbose output. Figure 9-2 displays the output of the jar command with the v option. The preceding figure shows that the classes.jar file produced is compressed. However, you can avoid this compression by the following command. jar cvf0 classes.jar *.class

The 0 option stores the files in a JAR file without compressing them. Refer to Figure 9-3 and compare this output with Figure 9-2.


Chapter 9

FIGURE 9-2 Using the v option with the jar command

FIGURE 9-3 Using the 0 option with the jar command

Let’s consider another example where the C:\clock directory contains the class files and images directory of the Clock applet. The following code statement creates a clock.jar file that packages this applet. jar cvf clock.jar *.class images

The preceding command stores the class files and the images directory in the clock.jar file. Therefore, the image files are stored in the images directory in the resulting JAR file as shown in Figure 9-4. The preceding example shows that the JAR files retain their relative pathnames and directory structure. However, you can change this by using the -C option with the jar command. Consider the following code statement: jar cf images.jar -C images

215

216

Part II


FIGURE 9-4 The creation of clock.jar file with the images directory

You’ll have to issue the preceding command from the parent directory of the images directory. The -C option directs the jar tool to the images directory and the . (period) following the -C images text directs the tool to archive all the contents of the images directory. In this section, you learned about the different options used for creating JAR files. In the next section, I’ll discuss how to view the contents of JAR files.

Viewing the Contents of JAR Files You can view the contents of a JAR file by using the following command: jar tf [jar-file]

As seen in the preceding code statement, there are two options that you see with the jar command. Let’s discuss these options. ◆ The t option specifies that you wish to view the table of contents of the

specified JAR file. ◆ The f option indicates that the JAR file whose contents you wish to view is specified at the command line. If this option is missing, the jar tool expects

a file name to be provided by the standard input device. The command displays the contents of the JAR file on the standard output device. Consider the code statement given here: jar tf clock.jar


Chapter 9

FIGURE 9-5 Contents of the clock.jar file

The preceding command displays the output of the JAR file, as shown in Figure 9-5. If you use the v option along with the preceding command, the jar tool displays additional information such as the file size and the modification date. Consider the following code statement: jar tvf clock.jar

The output of the preceding command with the v option is shown in Figure 9-6. You can compare Figures 9-5 and 9-6 to understand the difference between the two outputs. You have learned to create and view JAR files. Now, I’ll discuss how to extract the contents from JAR files in the subsequent section.

FIGURE 9-6 Contents of the clock.jar file with the v option of the jar tool

217

218

Part II


Extracting the Contents of JAR Files The syntax for using the jar command to extract fields from a JAR file is as follows: jar xf [jar-file] [archived-file(s)]

The preceding command has two new options, which are discussed here: ◆ The x option indicates that files need to be extracted from the specified JAR

file. ◆ The f option specifies that the JAR file from which the files are to be

extracted are specified at the command prompt. If this option is not specified, the file is supplied through the standard input device. In the preceding command, [jar-file] is the JAR file from which you need to extract files, and [archived-file(s)] are the files that need to be extracted from the archive file. When the jar tool extracts files, the original JAR file is not changed. Copies are made of the desired files and are written to the current directory in a similar directory structure as in the original JAR file. Consider the code statement given here: jar xf clock.jar ImageItem.class images/web.gif

The preceding command creates a copy of the ImageItem.class in the current directory. It also creates an images folder if it does not already exist and stores a copy the web.gif image in this directory. However, while extracting files, the clock.jar file is unchanged.

Updating JAR Files You can update an existing JAR file by adding new files to it. The syntax of the jar tool command for updating JAR files is specified here: jar uf [jar-file] [new-file(s)]

There is a new option specified in the preceding syntax. The u option indicates that you need to update the specified JAR file by adding the files specified by the [newfile(s)] keyword. If you try adding a file that already exists, the earlier file is overwritten by the latest version of the file. If you want to modify the manifest file contained in the JAR file, you can use the m option. Consider the code statement specified here: jar umf manifest [jar-file]


Chapter 9

In this case, the file specified by the manifest keyword does not replace the existing manifest file in the specified JAR file. Instead, the contents of the latest manifest file are merged into the earlier manifest file. Consider the code statement given here: jar uf clock.jar images/cart.gif

This statement adds the cart.gif file in the images directory to the clock.jar file. You can view the contents of the clock.jar file to verify whether the file has been added. Refer to Figure 9-7 for details.

FIGURE 9-7 Updating the clock.jar file and verifying its contents for

the new image added

I’ve already discussed the creating of JAR files. The next section covers how to run the applets and the applications packaged in these JAR files.

Running the Software Packaged in JAR Files You are already aware that you can store both applets and applications in a JAR file. You might now be wondering how to run a JAR file in a browser or at the command prompt. First, I’ll discuss running the applets packaged in JAR files. When you run an applet inside a browser, you need to specify the APPLET tag in the HTML file. On the other hand, if the applet is packaged in a JAR file, you can specify the relative path of the JAR file by using the Archive parameter. For example, consider an applet, Clock, with the class, Clock.class. The APPLET tag in the HTML file is specified here:

219

220

Part II


The following would be the APPLET tag specification for the Clock applet that is bundled in a JAR file.

The preceding example assumes that the JAR file and the HTML file are in the same location. However, if they are in different locations, you need to specify the relative path of the JAR file. You can run Java applications packaged in JAR files by using the following command: java -jar [jar-file]

The -jar flag indicates that the application to be executed is in the specified JAR file. How do you know the class that begins execution in a Java application? To indicate this class, you need to add the Main-Class header in the manifest of the specified JAR file. The header is specified as: Main-Class: Clock

Therefore, the application starts execution from the Clock class. I’ll now discuss the jarsigner tool in the subsequent section.

The jarsigner Tool You are already aware that the jarsigner tool is used to sign the JAR files created by the jar tool. It is also used to verify the signatures on these JAR files. A digital signature is a string of bits that is derived from the data that needs to be signed by the private key of a person or company. A digital signature has many unique features that help in maintaining the security for any application. These features are listed here: ◆ A digital signature can be easily authenticated because it is derived from a

computation. Therefore, it can also be verified by a computation. This computation uses the public key associated with the private key that is used to generate the signature. ◆ The data signed by a digital signature cannot be changed; otherwise, it will

not be authenticated in the verification phase. ◆ A digital signature is unique to the data it signs. It cannot be used to sign

another piece of data.


Chapter 9

◆ A digital signature cannot be forged because the private key is kept secret by

password protection. To sign the data, a person or company should have a public/private key pair associated with the signature and certificates authenticating the public key. The jarsigner tool uses the certificate and key information from the keystore to sign JAR files. This tool basically uses the private key of an entity to generate a digital signature. Note that the jarsigner tool can only sign the JAR files created by the jar tool. A signed JAR file contains a copy of the certificate from the keystore. This certificate is for the public key associated with the private key that is used to sign the JAR file. There are many code signing algorithms. However, the jarsigner tool can use either the RSA algorithm with the MD5 digest algorithm or the Digital Signature Algorithm (DSA) with the SHA-1 digest algorithm. The basic syntax of the jarsigner tool is specified here: jarsigner options jar-file alias

The options keyword specifies the additional options that can be used with this command. These options will be discussed in the subsequent section. The jar-file keyword represents the JAR file that needs to be signed. The alias keyword represents the alias identifying the private key that is used to sign the file. It also identifies the associated public key and keystore certificate. The basic syntax of the jarsigner tool when it is used for signature verification is given here: jarsigner -verify [options] jar-file

I’ll now discuss the contents of a signed JAR file after the jarsigner tool signs it.

Contents of Signed JAR Files The output JAR file that is signed is similar to the original unsigned JAR file, except that two additional files are placed in the META-INF directory. These files are a signature file with an .SF extension and a signature block file with a .DSA extension. The names of these files are derived from the -sigfile option. Consider the code here, which is a part of the jarsigner command: -sigfile classes

The preceding code creates two files, namely classes.SF and classes.DSA. The SF file is similar to the manifest file contained in any JAR file. It contains the file name, the name of the SHA digest algorithm used, and the SHA digest value. The DSA file

221

222

Part II


contains the signature after the SF file is signed. It also contains keystore information, such as the public keys and the certificates associated with the private key that is used to sign the specified JAR file. This information is encoded in the DSA file. Multiple people can sign a specified JAR file. All you have to do is execute the jarsigner command on the specified JAR file multiple times, specifying a different alias every time. For example, consider the code statements specified here: jarsigner classes.jar Laurie jarsigner classes.jar Caryl jarsigner classes.jar Michael

In the case of multiple signatures, there are multiple SF and DSA files because they are generated for every signature. The classes.jar file then contains the files: Laurie.SF, Laurie.DSA, Caryl.SF, Caryl.DSA, Michael.SF, and Michael.DSA. Let’s discuss the various options associated with the jarsigner command-line tool.

Options Associated with the jarsigner Tool When you simply enter the jarsigner command at the command prompt without any other options, an entire listing of the various command options is displayed at the command prompt. Refer to Figure 9-8 for the same.

FIGURE 9-8 Options associated with the jarsigner command


Chapter 9

Let’s discuss the use of these options in detail. Certain features are common to all the options. All the options have a minus sign (-) before them. The options can be provided in any order. The values following the specified option are the values that must be supplied with the command.

The -keystore Option The syntax of this option is specified here: -keystore

This option specifies the URL of the keystore location. The default keystore is stored as a .keystore file in the user’s home directory. If the default keystore is missing, you need to specify a keystore location using this option. The keystore is required while signing files. However, it is not needed when the jarsigner command is used to verify signatures. The in the preceding code statement can be replaced either by a file name or a path name. It can also be replaced by a file URL.

The -storepass Option The syntax of this option is specified here: -storepass <password>

This option specifies the password used to protect the keystore. This password is needed when the keystore is accessed while signing a JAR file. It is not needed when the jarsigner command verifies the signature of a JAR file. If this option is not specified, the user is prompted for the password.

The -storetype Option The syntax of this option is specified here: -storetype

This option specifies the type of keystore to be used while signing JAR files. The default keystore file is saved in the user’s home directory. The default keystore type is identified by the value contained in the keystore.type property in the security properties file. The getDefaultType() method of the java.security.KeyStore class returns this value.

The -keypass Option The syntax of this option is specified here: -keypass <password>

223

224

Part II


This option specifies the password for the private key that is used by the jarsigner tool to sign files. This private key belongs to the keystore entry identified by the alias name specified in the jarsigner command. If this option is not specified and the private key password is different from that of the keystore password, the user is prompted for the password. The keystore and private key password should be handled with care and secrecy. You should not type the password in front of anyone to maintain its secrecy. This is because the password entered at the prompt is not hidden by asterisks, instead it is echoed on the screen. Make it a habit to close the command prompt window after issuing any such command. Otherwise, any user can scroll up to see the password information.

The -sigfile Option The syntax of this option is specified here: -sigfile

This option has already been discussed in the preceding section. It specifies the base name to be used for the SF and DSA files. The keyword specified in the preceding code statement can take characters such as letters, a hyphen, an underscore, and numbers. All lowercase characters are automatically converted to uppercase characters for SF and DSA file names. If this option is not specified, the base name for these files is the same as the first eight characters of the alias name specified by the jarsigner command. If the alias name has less than eight characters, the full alias name is used. The alias name is automatically converted to uppercase characters. If the alias name contains any restricted characters, these are replaced by the underscore (_) character while forming the basic name.

The -signedjar Option The syntax of this option is specified here: -signedjar

This option specifies the name to be used for the signed JAR file. If this option is not specified, the original file name is retained. The signed JAR file replaces the original JAR file.

The -verify Option When this option is specified along with the jarsigner command, it indicates that the JAR file provided will be verified for its signature. If the JAR file supplied is not


Chapter 9

signed or is signed with an unsupported algorithm, a suitable message is displayed on the screen. The message, jar verified, is displayed when the JAR file verification is successful.

The -verbose Option This option indicates that a verbose output will be supplied at the command prompt. When this option is specified, the jarsigner command displays additional information related to signing and verification.

The -certs Option This option displays certificate information for every signer of the JAR file. This is possible only when the -verify and -verbose options are also specified with this option. The information displayed contains the distinguished name of the signer, if the certificate is a X.509 certificate. Information such as the type name of the certificate that certifies the signer’s public key is also printed.

The -internalsf Option In the previous versions, the DSA file contained an encoded copy of the SF file. However, this increased the overall size of the output JAR file. Therefore, now the DSA file does not contain a copy of the SF file. However, the previous version functionality—the DSA file that contained an encoded copy of the SF file—can be restored by using this option.

The -sectionsonly Option This option does not allow the SF file to include the header containing the hash of the manifest file. Therefore, with this option, the SF file contains only information and hashes related to each individual source file created in the JAR file.

Use of the jarsigner Tool The security tools, namely the keytool, jar, and jarsigner tools, work collectively to ensure the security of the system. For example, you can use data or code downloaded from a Web site or the network. This signed code and data can be verified for authenticity and integrity by the jarsigner tool. Consider a situation where you create a JAR file containing all the class files and images of an application. You transfer this file over the network to a destination location. For security purposes, you need to send your authenticity certificate along with the JAR file to the destination location. You sign the JAR file and export the associated certificate to the destination location. The user at

225

226

Part II


the destination location imports the certificate and verifies the signature on the signed JAR file. The entire process discussed is outlined by a series of keytool and jarsigner commands. I’ll discuss the various steps involved in the preceding example. You are already aware of the use of the keytool command to create a keystore and a private key pair. Imagine that you have already created a keystore named myStore, which has a key pair and an associated self-signed certificate. To review, a keystore is created by using the keytool -genkey option. The key pair and the self-signed certificate are associated with the alias, CJKey. The generation of the keystore, key pair, and self-signed certificate is illustrated in Figure 9-9. Next, you need to sign the JAR file with the private key created. Assume that you have created a classes.jar file. To sign the JAR file with the private key generated, you’ll write the following command at the command prompt. jarsigner -keystore myStore classes.jar CJKey

The output is displayed in Figure 9-10. Therefore, the classes.jar file is signed by using the private key information from the myStore keystore. Even though you did not specify the private key password in the command, you were not prompted for it because it is same as the keystore password. Now, the JAR file is signed and the self-signed certificate is also created. However, you need to export this self-signed certificate to a file so that you can send it to the destination. This can be done by using the keytool command as specified here: keytool -export -keystore myStore -alias CJKey -file Caryl.crt

The output is displayed in Figure 9-11.

FIGURE 9-9 Creation of the key pair and self-signed certificate


Chapter 9

FIGURE 9-10 Signing the classes.jar file with the CJKey

FIGURE 9-11 Exporting self-signed certificate to a file

Therefore, the preceding command creates a file, Caryl.crt, with the self-signed certificate. Now, you can send the signed classes.jar file along with your authentication certificate, which is stored in the Caryl.crt file, to the destination location. The person receiving the JAR file and certificate needs to verify the certificate and import it to the keystore on his/her computer. The following command performs this operation: keytool -import -file Caryl.crt -keystore destStore

The output is displayed in Figure 9-12. As you can see from the preceding figure, the file containing the self-signed certificate is imported to the keystore, destStore, on the destination computer.

227

228

Part II


FIGURE 9-12 Importing a self-signed certificate to the destination keystore

The preceding command asks the users whether they trust the certificate. The certificate is imported to the keystore only if the user enters y. Certificate information such as the owner, issuer, validity, and fingerprints are also displayed at the command prompt. Because no alias is mentioned for destStore, the certificate is stored in the keystore with the default alias, myKey. The person receiving the certificate information should first verify it before trusting it and adding it to the keystore. This can be done by asking the sender to mail the certificate information such as the fingerprints. The two sets of fingerprints can then be compared to verify that the certificate has not been tampered with during transit. The final step is to verify the signature on the signed JAR file. This can be done by the following command: jarsigner -verify -verbose -keystore destStore classes.jar

The output is displayed in Figure 9-13. If the JAR file is not signed, the preceding command will display the output as in Figure 9-14. On the other hand, if the files in the JAR file have been modified, the verification of the JAR file will result in an error. The last security-related tool is the policy tool. I’ve already discussed the policy tool in detail in Chapter 1, “Security: An Overview”. You are aware that the policy tool is used to create a policy file. You can add policy entries, modify them, delete them, and change the keystore by using the policy tool.


Chapter 9

FIGURE 9-13 Verifying the signature of the classes.jar file

FIGURE 9-14 Verifying the signature of the unsigned classes.jar file

Summary In this chapter, I discussed the various security tools in Java 2. I discussed the keytool command with its various options. The keytool command is used to manage the keystore. Then, I discussed the jar tool, which is used to create JAR files. I discussed all the operations performed by the jar tool. Finally, I discussed the jarsigner tool, which is used to sign JAR files and verify the signatures on them.

229

230

Part II


Check Your Understanding Multiple Choice Questions 1. Which of the following keytool command options is used to generate a key pair that constitutes the public key and its associated private key? a. -certreq b. -genkey c. -import d. -export 2. The f option of the jar command does which of the following? a. Creates a JAR file. b. Stores the files in a JAR file without compressing them. c. Directs the output to a JAR file instead of stdout. d. Includes manifest information from an existing manifest file. 3. Which of the following code statements displays the contents of the JAR file on the standard output device? a. jar tf [jar-file] b. jar t [jar-file] c. jar cf [jar-file] [input-file(s)] d. jar tvf [jar-file] 4. What does the following code statement do? jar xf myfile.jar MyItem.class images/myimage.gif

a. Runs the Java application packaged in the myfile.jar file. b. Creates a copy of the MyItem.class in the current directory. It also creates an images folder if it does not already exist and stores a copy of the myimage.gif image in this directory. c. Lists the contents of the myfile.jar file and stores the images in the images folder. d. Adds the myimage.gif file in the images folder to the myfile.jar file. 5. Which of the following statement(s) is true about the jarsigner tool? a. The jarsigner tool uses the certificate and key information from the keystore to sign JAR files. b. The jarsigner tool can only use the RSA algorithm with the MD5 digest algorithm.


Chapter 9

c. The jarsigner tool can only sign the JAR files created by the jar tool. d. The jarsigner tool can sign the JAR files created by other tools as well. 6. What is the use of the -sigfile option with the jarsigner tool? a. This option specifies the base name to be used for the SF and DSA files. b. This option does not allow the SF file to include the header containing the hash of the manifest file. c. This option specifies the password for the private key that is used by the jarsigner tool to sign files. d. This option displays certificate information for every signer of the JAR file.

Short Questions 1. The C:\Accounts directory contains the class files and images directory of the Accounts applet. Create an accounts.jar file that packages the class files and images of this applet. Extract the MyAcc.class file and Acc.gif from the accounts.jar file. Add a new image file, accsheet.gif, to the accounts.jar file. 2. What do signed JAR files contain? 3. Explain the difference of running Java applets and applications packaged in JAR files.

Answers Multiple Choice Answers 1. b. The -genkey option generates a key pair that constitutes the public key and its associated private key. 2. c. The f option of the jar command directs the output to a JAR file instead of stdout. 3. a. The jar tf [jar-file] statement displays the contents of the JAR file on the standard output device. 4. b. The code statement creates a copy of the MyItem.class in the current directory. It also creates an images folder if it does not already exist and stores a copy of the myimage.gif image in this folder. 5. a and c. The jarsigner tool uses the certificate and key information from the keystore to sign JAR files. This tool basically uses the private key of an

231

232

Part II


entity to generate a digital signature. Note that the jarsigner tool can only sign the JAR files created by the jar tool. A signed JAR file contains a copy of the certificate from the keystore. This certificate is for the public key associated with the private key that is used to sign the JAR file. There are many code signing algorithms. However, the jarsigner tool can use either the RSA algorithm with the MD5 digest algorithm or the Digital Signature Algorithm (DSA) with the SHA-1 digest algorithm. 6. a. The -sigfile option specifies the base name to be used for the SF and DSA files.

Short Answers 1. The C:\Accounts directory contains the class files and images directory of the Accounts applet. To create an accounts.jar file that packages the class files and images of this applet, you’ll use the following code statement: jar cvf accounts.jar *.class images

The preceding command stores the class files and the images directory in the accounts.jar file. To extract the MyAcc.class file and Acc.gif from the accounts.jar file, you’ll use the following code statement: jar xf accounts.jar MyAcc.class images/ Acc.gif

To add a new image file, accsheet.gif, to the accounts.jar file, you’ll use the following code statement: jar uf accounts.jar images/ accsheet.gif

2. The output JAR file that is signed is similar to the original unsigned JAR file, except that two additional files are placed in the META-INF directory. These files are a signature file with an .SF extension and a signature block file with a .DSA extension. The names of these files are derived from the sigfile option. Consider the code here, which is a part of the jarsigner command: -sigfile clock

The preceding code creates two files, namely classes.SF and classes.DSA. The SF file is similar to the manifest file contained in any JAR file. It contains the file name, the name of the SHA digest algorithm used, and the SHA digest value. The DSA file contains the signature after the SF file is signed. It also contains keystore information, such as the public keys and the


Chapter 9

certificates associated with the private key that is used to sign the specified JAR file. This information is encoded in the DSA file. 3. You can store both applets and applications in a JAR file. When you run an applet inside a browser, you need to specify the APPLET tag in the HTML file. On the other hand, if the applet is packaged in a JAR file, you can specify the relative path of the JAR file by using the Archive parameter. For example, consider an applet, Game, with the class, Game.class. The APPLET tag in the HTML file is specified here:

The following would be the APPLET tag specification for the Game applet that is bundled in a JAR file:

The preceding example assumes that the JAR file and the HTML file are in the same location. However, if they are in different locations, you need to specify the relative path of the JAR file. You can run Java applications packaged in JAR files by using the following command: java -jar [jar-file]

The -jar flag indicates that the application to be executed is in the specified JAR file. To know the class that begins execution in a Java application, you need to add the Main-Class header in the manifest of the specified JAR file. The header is specified as: Main-Class: Game

Therefore, the application starts execution from the Game class.

233


Chapter 10 An Introduction to Java Plug-ins

Y

ou are aware that Sun releases new versions of Java SDK from time to time. Browser vendors try to keep up with these versions by incorporating changes in their browser software almost simultaneously. However, their browsers are unable to keep up with all the changes made in the new version release of Java SDK. Therefore, corporate intranet developers are often deprived of these new Java SDK features because the corresponding changes are not present in the new browser release.

Sun has solved this problem by introducing the plug-in architecture via the Java plugin. The Java plug-in is software from Sun Microsystems that allows Web developers to run Java applets or JavaBeans components in their Web pages by using the JRE instead of the browser’s default JVM. This software comes with the installation of JRE 1.2x and Java 2 SDK. In this chapter, I’ll discuss features of the Java plug-in in detail. I’ll also explain the role of the Java plug-in.

The Features of the Java Plug-in The Java plug-in acts as a layer between the JRE and the browsers. It integrates all the features and capabilities of Java 2 in popular browsers such as Netscape Navigator and Microsoft Internet Explorer. Thus, when Sun adds new features to the Java 2 SDK, developers can access these features in Internet Explorer and Navigator by using the latest release of the Java plug-in. Now, let’s discuss the basic features of the Java plug-in. ◆ The Java plug-in provides full support to developers for creating applets that

use all the features of Java 2 SDK version 1.2 and higher. This support is provided both on Netscape and Internet Explorer. The plug-in allows signed classes to be loaded in these browsers, and these applets are subject to the recent changes in the Java 2 security model. Before the emergence of the Java plug-in, developers could not use the new features of the new version release because these features were not incorporated in their browser. ◆ The Java plug-in provides a future-ready Java 2 SDK architecture. This

indicates that whenever a new version of Java 2 with new features enters the market, these features are immediately available on popular browsers by using the Java plug-in.

AN INTRODUCTION TO JAVA PLUG-INS

Chapter 10

◆ The Java plug-in provides an easy download and install procedure. When a

Web page that requires Java plug-in support is encountered, the browser downloads and installs all the necessary files. In this way, there is minimal user intervention when a particular applet is being executed. ◆ The Java plug-in provides a free Java plug-in HTML converter that modi-

fies the HTML pages that are using Java plug-ins. This saves the overhead of modifying the browser’s default JRE environment. Now, let’s discuss how to install and run the Java plug-in on both Internet Explorer and Netscape Navigator.

Installing the Java Plug-in I’ve already discussed that when an applet requiring Java plug-in support is loaded in a browser, the browser downloads and installs all the necessary files. Please note that this holds true only if the Java plug-in is not already installed. I’ll first discuss the process in Netscape Navigator. When Navigator encounters a Web page that requires plug-in support, a plug-in missing picture and the Plug-in Not Loaded dialog appears on the page that prompts for installing the plug-in from the Sun site. Refer to Figure 10-1 for this prompt. Users can click the Get the Plugin button to start the Java plug-in download process. Once the plug-in is installed, the prompt in Figure 10-1 will not appear again. Therefore, the applets requiring plug-in support will execute without user intervention. Now, I’ll discuss the Java plug-in download process in Internet Explorer. When Internet Explorer encounters a Web page that requires plug-in support, a Security Warning dialog appears, asking whether the user needs to download an ActiveX control that is digitally signed by Sun Microsystems and can be verified by using the associated VeriSign certificate. Refer to Figure 10-2 for this security warning. When the user clicks the Yes button in the Security Warning dialog, an installation dialog appears, as in Figure 10-3.

FIGURE 10-1 The Plugin Not

Loaded message box

237

238

Part II


FIGURE 10-2 The Security Warning dialog in

Internet Explorer

FIGURE 10-3 The Java Plugin

Installation dialog

This dialog box allows you to select the appropriate locale-specific JRE. When the user clicks on the Install button, a Downloading dialog appears, as shown in Figure 10-4. The plug-in and the JRE ActiveX files are automatically downloaded and installed. The download and installation time depends upon the network connection and overall system performance. The next time when Internet Explorer encounters a Web page that requires plug-in support, it automatically loads and runs the downloaded ActiveX control. Now, let’s discuss what the Java plug-in actually does to fulfill its purpose.


Chapter 10

FIGURE 10-4 The Downloading dialog

The Role of the Java Plug-in The main role of the Java plug-in is to provide applets support for all the features and capabilities in Java 2 SDK. This cannot hold true if the particular Web page uses the default runtime supported by the browser because these changes have not been incorporated in it. However, the Java plug-in does not replace or modify the default browser runtime. Using the Java plug-in, Web page developers can specify the use of Sun’s JRE instead of the default runtime. Let’s discuss how the browsers, Netscape Navigator and Internet Explorer, use Sun’s JRE in Web pages. You can run Sun’s JRE in Navigator by using its plug-in architecture. Web page developers can use the <EMBED> HTML tag in place of the <APPLET> tag to run plug-ins as part of a Web page. Therefore, using this tag, Web developers can also run the Sun’s JRE in Navigator. You can use Microsoft technologies, such as COM and ActiveX, to allow Sun’s JRE to run within Internet Explorer. Web page developers can use the HTML tag in place of the <APPLET> tag to run ActiveX or COM components in a Web page. Moreover, Internet Explorer provides methods for downloading ActiveX controls and storing them in the local cache. This eliminates the need for user intervention every time a Web page requiring plug-in support is downloaded. As seen in the preceding discussion, Web page developers need to modify their Web pages to support the Java plug-in. You can do this either manually or by using the HTML converter. I’ll discuss these HTML changes in the subsequent section.

Modifying HTML Code for Java Plug-in Support You are aware that to use the Java plug-in a particular Web page, you need to replace the <APPLET> tag with the Java plug-in tags, namely and <EMBED>. First, let’s observe the <APPLET> tag in an HTML file.

239

240

Part II


<APPLET code = “MySource.class” codebase=“html/” align=“baseline” width=“200” height=“200”>

In the preceding code, the <APPLET> tag specifies information about the applet, such as the height, width, code class, and codebase. On the other hand, the tag stores information for every applet instance. The <APPLET> tag forces the browser to execute the applet and use its own JRE instead of Sun’s JRE. Therefore, to use the Java plugin, you need to replace the <APPLET> tag with the and <EMBED> tags. In the subsequent sections, let’s discuss the HTML changes required for Java plug-in support in: ◆ Netscape Navigator ◆ Internet Explorer ◆ Both Netscape Navigator and Internet Explorer ◆ All the browsers

Changes for Netscape Navigator As already discussed in the preceding section, for the Java plug-in to be used in Navigator, you need to replace the <APPLET> tag with the <EMBED> tag. Consider the <APPLET> tag discussed in the preceding section: <APPLET code = “MySource.class” codebase=“html/” align=“baseline” width=“200” height=“200”>

Now, let’s replace the <APPLET> tag with the <EMBED> tag. The resulting code is given here: <EMBED type=”application/x-java-applet;version=1.2.2” width=”200” height=”200” align=”baseline” code=”MySource.class” codebase=”html/” MyApplet=”MySourceApplet” pluginspage=”http://java.sun.com/products/plugin/1.2/plugin-install.html”> Failed to start Java Plug-In!!!!


Chapter 10

Now, let’s observe the differences in the attributes of both the tags. The sequence of information remains more or less the same. The attributes, such as code, codebase, width, height, and align, are the same in both the tags. The tag attributes are also included in the <EMBED> tag itself. However, there are certain new attributes in the <EMBED> tag, which are listed here: ◆ The type attribute identifies the type of the Java component, whether

applets or beans. When Navigator accesses this attribute, it loads the Java plug-in. Using this attribute, the Java plug-in decides how to initialize the Java component. ◆ The pluginspage attribute identifies the Java plug-in download page. How-

ever, this value is used only if the Java plug-in is not already installed. The tag is used when the <EMBED> tag is not supported by the browser or the Java plug-in could not be loaded.

Changes for Internet Explorer For the Java plug-in to be used in Internet Explorer, you need to replace the <APPLET> tag with the tag. Consider the <APPLET> tag given here: <APPLET code = “MySource.class” codebase=“html/” align=“baseline” width=“200” height=“200”>

Now, let’s replace the <APPLET> tag with the tag. The resulting code is given here: Failed to start Java Plug-In!!!!

241

242

Part II


Now, let’s observe the differences in the attributes of both the tags. The sequence of information remains more or less the same. The attributes, such as width, height, and align, are the same in both the tags. However, not all the attributes can be mapped to the tag attributes. According to the HTML specification, there is no code attribute in the tag. However, the code attribute is mapped to the tag’s code attribute instead. Therefore, if the attributes do not correspond to the tag attributes, they are mapped to the tag attribute instead. The classid attribute identifies the class identifier of the Java plug-in and should contain the same value in every HTML page. In the <APPLET> tag, the codebase attribute identifies the location from where the class or JAR files are downloaded. However, in the tag, the codebase attribute indicates the Java plug-in download page. To resolve this conflict, a codebase attribute mapping to the <APPLET> tag is placed in the tag.

NOTE If the original <APPLET> tag already has the archive, codebase, code, object, and type attributes specified in the tag, duplicate PARAM names will appear if you map the attributes in the tag. However, this name clash can be avoided as the Java plug-in supports another set of PARAM names that are prefixed by java_. Some examples are java_archive, java_codebase, java_code, java_object, and java_type. However, these names should be used only when necessary.

Now, let’s discuss the changes when a Web page needs to be executed on both Netscape and Internet Explorer or on any other browser.

Changes for Both Netscape Navigator and Internet Explorer While viewing an HTML Web page on either the Internet or an intranet, it is possible to view the page in both Netscape Navigator and Internet Explorer. Therefore, the Web page should contain HTML changes that are supported by both these browsers. This can be done by using the Java plug-in tag, as given here. First, let’s examine the original applet code. <APPLET code = “MySource.class” codebase=“html/” align=“baseline” width=“200” height=“200”>


Chapter 10

Now, let’s replace the <APPLET> tag with the tag. The resulting code is given here: <EMBED type=”application/x-java-applet;version=1.2.2” width=”200” height=”200” align=”baseline” code=”MySource.class” codebase=”html/” MyApplet=”MySourceApplet” pluginspage=”http://java.sun.com/products/plugin/1.2/plugin-install.html”> Failed to start Java Plug-In!!!!

Notice that in the preceding code, you can use both the and <EMBED> tags to activate the Java plug-in when either of the browsers is used. The users in an intranet environment use this combined tag more frequently. There is only a new tag in the preceding code listing, which I’ll discuss here. This tag is understood only by Internet Explorer. The text enclosed within this tag is considered as a comment entry and ignored. The and tags are ignored by Navigator, which understands only the <EMBED> tag. In the subsequent section, I’ll discuss the changes supported by all the browsers.

Changes for All the Browsers Consider the following case. In an intranet, while loading a Web page that requires the Java plug-in, a user specifies another browser instead of Internet Explorer or Navigator. The Web page would not load because the subsequent HTML changes would not have been incorporated and the page would run in the default browser runtime. Because users can use any browser, the HTML code provided should be accessible by all browsers. Such a code listing is given here:

243

244

Part II


tag. —> <SCRIPT LANGUAGE=”JavaScript”> 0 && _info.indexOf(“Win”) > 0 && _info.indexOf(“Windows 3.1”) < 0); //—> <SCRIPT LANGUAGE=”JavaScript1.1”>= 0 && ((_info.indexOf(“Win”) > 0 && _info.indexOf(“Win16”) < 0 && java.lang.System.getProperty(“os.version”).indexOf(“3.5”) < 0) || _info.indexOf(“Sun”) > 0)); //—>

<SCRIPT LANGUAGE=”JavaScript”> <XMP>’); else if (_ns == true) document.writeln(‘ <EMBED type=”application/x-java-applet;version=1.2.2” width=”200” height=”200” align=”baseline” code=”MySource.class” codebase=”html/” MyApplet=”MySourceApplet” pluginspage=”http://java.sun.com/products/plugin/1.2/plugin-install.html”> <XMP>’); //—> <APPLET code=”MySource.class” codebase=”html/” align=”baseline” width=”200” height=”200”> Failed to start Java Plug-In!!!!


Chapter 10

Failed to start Java Plug-In!!!! —>

Don’t worry, the preceding code is not as complicated as it seems. Most of it remains similar irrespective of the applet used. Let’s discuss the changes in the preceding code. The first part of the code determines the browser type and the platform used by the applet. This is done by using JavaScript. This is provided at the beginning of the HTML tag. The second part of the script replaces the <APPLET> tag with either the <EMBED> or tags. Finally, the original <APPLET> tag is included at the end of the script. If the browser is Netscape, the <EMBED> tag is used. On the other hand, if the browser is Internet Explorer, the tag is used. Finally, if any other browser other than these two is specified, the <APPLET> tag is used.

The HTML Converter The HTML Converter software is used to convert HTML files so that they can use the Java plug-in. It performs the same task as the manual changes discussed in the preceding sections. This is a free tool, and you can download it from the http://java.sun.com site. You can run this tool by typing java HTMLConverter at the command prompt. This opens a window that appears as shown in Figure 10-5. Using the interface shown in Figure 10-5, you can convert the files in the specified folder. This software has a user-friendly interface that guides the conversion process. You can either convert all the files in the specified folder or convert a single file in it. The HTML Converter software preserves the original HTML files in a backup folder. If you are not satisfied with the changes or you need to modify the original file again, you can revert to the originals in the backup folder. As discussed in the preceding sections, the HTML changes are done for Netscape, Internet Explorer, both of them, or globally for all the browsers. You can perform similar operations for different browser platforms by selecting the suitable template file from the GUI interface. Now, in the subsequent section, let’s discuss the role of security in the Java plug-in.

245

246

Part II


FIGURE 10-5 The HTML Converter window

Security and the Java Plug-in The Java plug-in supports the standard Java 2 security model. This implies that all the applets run under the restrictions placed by the security manager and signed applets are allowed full access to the local system. The Java plug-in uses key and certificate management to implement security. This is provided by the keytool utility. The applets signed by a trusted cryptographic key are allowed to run and access all the resources of the local computer. The applets are stored in a JAR file that is signed by a trusted identity. A JAR file can be downloaded by using the HTTP protocol. However, for this downloaded JAR file to access the local resources, the system should be able to verify the signature attached to it. In Java 2, there are methods for distributing signed Java code for Netscape Navigator and Internet Explorer. In the case of Netscape, the applet code is zipped in a JAR file and is signed using a VeriSign certificate. The signature format supported by Netscape is RSA, and the message digest algorithm used is SHA-1. However, in the case of Internet Explorer, the code is placed in a CAB file and is signed by using a VeriSign certificate. The signature format supported by Internet Explorer is RSA, and the message digest algorithm used is SHA-1. The VeriSign certificates used in Netscape and Internet Explorer are different. In Netscape, the VeriSign certificate is for Object Signing, whereas in Internet Explorer, the certificate is for Authenticode. On the other hand, if the applet is to be run on the Java 2 JRE, the code is put in a JAR file and is signed


Chapter 10

by using the keytool utility. The signature format is DSA, and the message digest algorithms supported are MD5 and SHA-1. These are not the only differences related to signed code. There are different implementations for policies and permissions in Netscape, Internet Explorer, and the Java 2 runtime environment. In Netscape, you can use the cert7.db file to store the certificates on a certificate server. In Internet Explorer, you can use the system and user stores provided by Microsoft. In the Java 2 runtime environment, you can use keystores to store the private keys and certificates. The cacerts file stores the certificates of certification authorities. Due to these differences and because the implementations discussed previously are not compatible, you would need to write three code implementations for each of the platforms discussed. However, don’t worry. The Java plug-in saves you all this effort. It allows you to use the code signed by using the Java 2 runtime implementation in Netscape and Internet Explorer. There are certain constraints. For instance, you can use only the Java 2 signing method and the certificate and key implementations of Netscape and Internet Explorer are not supported. However, you can overlook these constraints because the Java plug-in provides the advantage of portability. In the previous versions of the Java plug-in, only DSA support was provided. There was no support for RSA, which is used by Netscape and Internet Explorer. However, now, the Java plug-in includes support for RSA-signed applets as well. The advantage of using this algorithm is that you don’t need to use security files for each user computer. RSA support is available both in Netscape and Internet Explorer. It also provides dialog boxes that pop up on the screen and help users to validate signers. The Java plug-in control panel contains the Certificates panel that manages RSA-signed applets. The panel contains a list of certificates that grant an applet AllPermission. You’ll read more about the Java plug-in control panel in a subsequent section. In the next section, I’ll discuss how to run applets with the Java plug-in.

Applets and Java Plug-ins In this section, I’ll discuss a sample Java applet and try to run it in Internet Explorer. First, I’ll run the Java applet without the Java plug-in support and see the consequences. The following is the code listing of the MyApplet.html file that provides the source class name, which is MyApplet.class. This file uses the <APPLET> tag. <TITLE>Using the Java Plug-in

247

248

Part II


The Big ‘Q’
Will the Applet Run???
<APPLET code=”MyApplet.class” Width=200 Height=30>

Now, let’s see the code listing of the MyApplet.java file. import java.io.*; import java.applet.*; import java.awt.Graphics; import java.lang.*; public class MyApplet extends Applet { String myFile = “/test.txt”; File f = new File(myFile); DataOutputStream dos; public void paint(Graphics g) { try{ dos = new DataOutputStream(new BufferedOutputStream (new FileOutputStream(myFile),128));

dos.writeChars(“Hello!! I’ve written

to this file!!!\n”); dos.flush(); g.drawString(“Writing to file successful”, 15,15); } catch(Exception e){ System.out.println(“Caught exception:”+e.toString()); g.drawString(“WriteFile: caught security exception”, 10, 10); } } }


Chapter 10

The preceding code attempts to write to the file test.txt. If the write operation is successful, the message, “Writing to file successful”, is displayed on the browser. If the write operation fails, the security exception thrown is displayed on the browser. This is because no permissions have been defined for the specified applet. Now, let’s use the Java plug-in while loading the applet in Internet Explorer. You’ll have to modify the MyApplet.html file and replace the <APPLET> tag with the tag, as shown in the following code listing: <TITLE>Using the Java Plug-in

The Big ‘Q’
Will the Applet Run???
Failed to start Java Plug-In!!!! —>

Now, let’s load this HTML file in the browser. The browser and the Java console window appear as shown in Figures 10-6 and 10-7. The Java console window appears because of the Java plug-in support in the modified MyApplet.html file. It displays the exception caught while trying to execute the applet on the HTML page. The exception also appears on the browser screen because all the Java 2 features are used while running the applet. Because the Java plug-in does not support dynamic permission prompting, the applet fails to execute. The reason for this is that the applet does not have the write permission set for the test.txt file.

249

250

Part II


FIGURE 10-6 The browser window running the MyApplet.html file with Java

plug-in support

FIGURE 10-7 The Java Console window

displaying AccessControlException


Chapter 10

You have to explicitly set this permission in the policy file. This can be done by adding the following grant entry to the policy file. grant codeBase “C:\MyApplet.java”{ permission java.io.FilePermission “C:/test.txt”, “write”; };

Now, the file can be accessed, and the suitable message is displayed on the browser screen.

The Java Plug-in Control Panel The Java plug-in control panel allows you to change the default settings of the plugin. These settings are used by all the applets running inside the Java plug-in. You can invoke the control panel from the Windows control panel. The control panel appears as in Figure 10-8. As shown in Figure 10-8, there are six tabs in the Control panel window. Let’s discuss these panels in the subsequent sections.

FIGURE 10-8 The Java Plug-in Control

Panel

251

252

Part II


The Basic Panel By default, the Java plug-in control panel opens with the Basic panel. You can set the following options by using this panel: ◆ The Enable Java Plug-in option enables the Java plug-in so that you can run

applets or JavaBean components. By default, it is checked. ◆ The Show Java Console option displays the Java console while running applets. The console displays the information sent by the System.err or System.out object. By default, this option is unchecked. ◆ The Recycle Classloader option allows the use of cached classloader while

running multiple applets in a browser session. This avoids the use of a new classloader for every applet. By default, this option is checked ◆ The Track Lifecycle Exception option traps exceptions as and when they

occur in the life cycle of an applet. This option is unchecked by default. ◆ The Java Runtime Parameters option allows you to override the Java plug-in

default startup parameters by specifying custom options.

The Advanced Panel The Advanced panel appears as shown in Figure 10-9. You can set the following options by using this panel: ◆ The Java RunTime Environment option enables a Java plug-in to run with

any JRE or Java 2 SDK. You can override the default JRE to use a newer or older version of the JRE. All the versions installed on your computer are

FIGURE 10-9 The Advanced panel


Chapter 10

automatically fetched and listed in the given list box. The list starts with the default JRE option. ◆ The Enable Just In Time Compiler option enables the JIT compiler. You

have to specify the path of the JIT compiler in the box provided. The compiler is located in the bin directory. By default, this option is checked. ◆ The Enable Debug option can be used only for the Internet Explorer

browser. You can check this box to enable debugging. You also have to specify the debug port. If this option is enabled, a window pops up prompting for the password.

The Proxies Panel The Proxies panel appears as shown in Figure 10-10. This panel has just one option, namely Use Browser Settings. You can use this option to use the browser’s default proxy settings. You can also specify your own settings by unchecking this option and specifying the new settings in the Proxy Settings section. You can enter the proxy address and the port of the different specified protocols, namely HTTP, Secure, FTP, Gopher, and Socks. If you want to use the same proxy settings for all the protocols, check the Same Proxy Server For All Protocols option.

The Cache Panel The Cache panel appears as shown in Figure 10-11. The Java Plug-in reuses the applet’s JAR files that have already been loaded in its cache, thereby ensuring the proper use of the memory resource. You can delete all of the JAR files stored in the cache by clicking the Clear JAR Cache button.

FIGURE 10-10 The Proxies panel

FIGURE 10-11 The Cache panel

253

254

Part II


I’ve already discussed the use of the Certificates panel in a previous section. It displays a list of certificates that grant an applet AllPermission. You can remove these certificates by clicking on the Remove button. The last panel is the About panel. It displays information about the current Java plugin version, JVM version, and Java 2 SDK version, as shown in Figure 10-12.

FIGURE 10-12 The About panel

Summary In this chapter, I discussed the Java plug-in and its features. Then, I explained the installation of the Java plug-in and what it actually does. Next, I discussed the HTML changes needed for running the Java plug-in in Netscape, Internet Explorer, both of them, and all the browsers. Then, I explained the concept of security, signed applets, and the Java plug-in. Finally, I discussed the various options in the Java plug-in control panel.

Check Your Understanding Multiple Choice Questions 1. How do the browsers, Netscape Navigator and Internet Explorer, use Sun’s JRE in Web pages? a. By using the <APPLET> tag. b. By using the tag. c. By using the tag. d. By using the <EMBED> tag.


Chapter 10

2. Which of the following statements identifies the role of the type attribute in the <EMBED> tag? a. It identifies the type of the Java component. b. It determines whether the HTML change is manual or automatic. c. It identifies the Java plug-in download page. d. It identifies the location from where the class or JAR files are downloaded. 3. Which of the following statements are true with respect to the tag? a. The classid attribute of the tag identifies the class identifier of the Java plug-in. b. In the tag, the codebase attribute indicates the Java plug-in download page. c. In the tag, the codebase attribute identifies the location from where the class or JAR files are downloaded. d. The tag also contains a codebase attribute mapping to the <APPLET> tag. 4. Which of the following statements are true with respect to the tag? a. This tag is added as an HTML change for both Netscape Navigator and Internet Explorer. b. This tag is added as an HTML change for all the browsers. c. This tag is understood only by Internet Explorer. d. This tag is understood only by Netscape Navigator. 5. How do you store certificates in Netscape? a. You use the cert7.db file. b. You use the system and user store. c. You use keystores. d. You use the cacerts file.

Short Questions 1. For the following <APPLET> tag, discuss the HTML changes required for Netscape and Internet Explorer. <APPLET code = “UseApplet.class” codebase=“html/” align=“baseline” width=“300” height=“300”>

255

256

Part II


2. Explain the differences in signed code with respect to Netscape and Internet Explorer.

Answers Multiple Choice Answers 1. c and d. Web page developers can use the <EMBED> HTML tag in place of the <APPLET> tag to run plug-ins as part of a Web page. Using this tag, Web developers can also run the Sun’s JRE in Navigator. Web page developers can use the HTML tag in place of the <APPLET> tag to run ActiveX or COM components in a Web page in Internet Explorer. 2. a. The type attribute identifies the type of the Java component, whether applets or beans. 3. a, b, and d. The classid attribute identifies the class identifier of the Java plug-in and should contain the same value in every HTML page. In the <APPLET> tag, the codebase attribute identifies the location from where the class or JAR files are downloaded. However, in the tag, the codebase attribute indicates the Java plug-in download page. To resolve this conflict, a codebase attribute mapping to the <APPLET> tag is placed in the tag. 4. a and c. The tag is understood only by Internet Explorer. The text enclosed within this tag is considered as a comment entry and ignored. The and tags are ignored by Navigator, which understands only the <EMBED> tag. 5. a. In Netscape, you can use the cert7.db file to store the certificates on a certificate server. In Internet Explorer, you can use the system and user stores provided by Microsoft. In the Java 2 runtime environment, you can use keystores to store the private keys and certificates. The cacerts file stores the certificates of certification authorities.

Short Answers 1. Here’s the original <APPLET> tag: <APPLET code = “UseApplet.class” codebase=“html/” align=“baseline” width=“300” height=“300”>


Chapter 10

The HTML changes in Netscape are as follows: <EMBED type=”application/x-java-applet;version=1.2.2” width=”300” height=”300” align=”baseline” code=” UseApplet.class” codebase=”html/” Name=”SourceApplet” pluginspage=”http://java.sun.com/products/plugin/1.2/plugininstall.html”> Failed to start Java Plug-In!!!!

The HTML changes in Internet Explorer are as follows: Failed to start Java Plug-In!!!!

2. In Java 2, there are different methods for distributing signed Java code for Netscape Navigator and Internet Explorer. In the case of Netscape, the applet code is zipped in a JAR file and is signed using a VeriSign certificate. The signature format supported by Netscape is RSA, and the message digest algorithm used is SHA-1. However, in the case of Internet Explorer, the code is placed in a CAB file and is signed by using a VeriSign certificate. The signature format supported by Internet Explorer is RSA, and the message digest algorithm used is SHA-1. The VeriSign certificates used in Netscape and Internet Explorer are different. In Netscape, the VeriSign certificate is for Object Signing, whereas in Internet Explorer, the certificate is for Authenticode. On the other hand, if the applet is to be run on the Java 2 JRE, the code is put in a JAR file and is signed by using the keytool utility. The signature format is DSA, and the message digest algorithms supported are MD5 and SHA-1. These are not the only differences related to signed code. There are different implementations for policies and permissions in Netscape, Internet Explorer, and the Java 2 runtime environment.

257

258

Part II


In Netscape, you can use the cert7.db file to store the certificates on a certificate server. In Internet Explorer, you can use the system and user stores provided by Microsoft. In the Java 2 runtime environment, you can use keystores to store the private keys and certificates. The cacerts file stores the certificates of certification authorities.

Chapter 11 Message Digests and Digital Signatures

I

n this chapter, I’ll discuss cryptographic techniques, which help in maintaining the secrecy of messages, files, and other objects. These techniques support integrity by checking whether a message or object has been modified or replaced. You can also authenticate a particular message or object by verifying that it originated from the specified identity. Message digests and digital signatures are part of these cryptographic techniques. In the subsequent sections, I’ll discuss these concepts and their use in detail.

Message Digests Message digests are hash or one-way functions. A hash or one-way function is one that is easy to calculate, although difficult to reverse. Message digests for a specified message are also called its fingerprints. Message digests compute values that are called message digests or hash values. There are several message digest algorithms that are supported by Java 2, for example, Message Digest 5 (MD5) and Secure Hash Algorithm1 (SHA-1). The output of a message digest function should be unique so that the computed value cannot be derived through another message digest function. Two different messages cannot have the same message digest value. The original message cannot be derived by reversing the computed value. Even if the message digest is computed multiple times by using the same algorithm, a particular message produces the same message digest value.

NOTE Ron Rivest developed the MD5 algorithm, which is extended from the MD4 algorithm. This algorithm takes an input that can be any message of arbitrary length. It produces a 128-bit fingerprint or message digest of the supplied input. It is computationally not feasible to produce two different messages having similar message digests. It is also not possible to recreate a message based on a pre-specified message digest. This algorithm is used for digital signature applications in which you require to compress a large file before encrypting it with a secret key. This helps you to securely store or transfer the file. The SHA-1 algorithm was developed by National Institute of Standards and Technology (NIST). This algorithm operates on 264 bit messages and produces a 160-bit digest value. Therefore, it operates on a very large message size. It is also based on the MD4 algorithm.

MESSAGE DIGESTS AND DIGITAL SIGNATURES

Chapter 11

Base 64 Encoding The Base 64 encoding format provides a method to convert binary text to printable text so that it can be displayed on the screen or included in the message text. This encoding format works as follows: 1. The bytes that need to be converted are placed consecutively to form a 24-bit sequence. 2. This 24-bit sequence is organized into four 6-bit units. 3. Each of these units represents an integer value between 0 and 63. 4. Four characters are selected from the Base 64 codes by using these integer values. There might be situations where, at the end of a message, there are less than four bytes to convert. In this case, the padding technique is used to facilitate conversion. When you encode two bytes, they form a 16-bit sequence. Two zero bits are added to form an 18bit sequence. This is then organized into three 6-bit values. Base 64 codes substitute these characters. Finally, a fourth padding character (=) is appended to the three characters.

Classes and Interfaces for Message Digests In this section, I’ll discuss the classes and interface support for message digests provided in the java.security package. The java.security package provides four classes for message digests, which are listed here and explained in detail in the subsequent sections. ◆ MessageDigestSpi ◆ MessageDigest ◆ DigestInputStream ◆ DigestOutputStream

The MessageDigestSpi Class This is an abstract class that defines the service provider interface for developing MessageDigest classes. Abstract methods are defined in the MessageDigestSpi class to be implemented by a cryptographic service provider. The provider supplies the implementation of a specific message digest algorithm, such as MD5 or SHA.

NOTE The term Cryptographic Service Provider (CSP) refers to a package or a set of packages that supplies a concrete implementation of the cryptography aspects of the JDK security API. For example, JDK 1.2 comes with a default provider, named SUN.

261

262

Part II


The methods defined in this class are listed here: ◆ engineGetDigestLength() ◆ engineUpdate() ◆ engineDigest() ◆ engineReset() ◆ clone()

Let’s discuss the syntax and use of these methods in detail.

The engineGetDigestLength() Method The definition of this method is given here: protected int engineGetDigestLength()

This method returns the digest length in bytes. By default, it returns 0. This method can be overridden by a provider.

The engineUpdate() Method The definition of this method is given here: protected abstract void engineUpdate(byte input)

This method updates the message digest by using the specified byte input. This method is overloaded; the definition of the overloaded method is given here: protected abstract void engineUpdate(byte[] input, int offset, int len)

This method updates the message digest by using the specified array of bytes. However, the number of bytes to be used in this array is specified starting from the offset parameter and continuing to the number specified by the len parameter.

The engineDigest() Method The definition of this method is given here: protected abstract byte[] engineDigest()

This method completes the computation of the message digest by performing final operations such as padding. The method returns an array of bytes for the resulting hash value.


Chapter 11

This method is also overloaded, and the definition of the overloaded method is given here: protected int engineDigest(byte[] buf, int offset, int len) throws DigestException

This method completes the computation of the message digest. However, it stores the final digest value in the buf array as specified by the offset and len parameters. If the value specified by the len parameter is less than the actual digest length, the method throws DigestException. This method returns the length of the digest value stored in the output buffer.

The engineReset() Method The definition of this method is given here: protected abstract void engineReset()

This method resets the message digest to its initial starting point for further use.

The clone() Method The definition of this method is given here: public Object clone() throws CloneNotSupportedException

This method provides support for implementing the Cloneable interface. This method returns a clone, if the implementation is cloneable. If the implementation does not support the Cloneable interface, the method throws CloneNotSupportedException.

The MessageDigest Class This is an abstract class and provides applications the functionality of a message digest algorithm. The MessageDigest class extends from the MessageDigestSpi class. I’ll explain the life cycle of a MessageDigest object. To start with, a MessageDigest object is initialized. The digest data is processed by using the update() methods. The reset() method can be called at any time to reset the digest. After all the digest data has been updated, the digest() method is invoked to complete the hash computation. After this method is invoked, the MessageDigest object is reset to its initialized state. The syntax for the constructor of this class is defined here: protected MessageDigest(String algorithm)

263

264

Part II


The protected constructor creates a message digest with the algorithm specified by the string parameter. The MessageDigest objects are created by invoking the getInstance() method. A string specifying the algorithm is passed to this method. An example is: MessageDigest md = new MessageDigest.getInstance(“SHA”);

Let’s discuss the methods defined in the MessageDigest class.

The getInstance() Method The definition of this method is given here: public static MessageDigest getInstance(String algorithm) throws NoSuchAlgorithmException

This method creates a MessageDigest object that implements a specified digest algorithm. First, the default provider is checked for the specified digest algorithm. If the algorithm is not present in the default package, other packages are searched. If the specified algorithm is not present in the caller’s environment, NoSuchAlgorithmException is raised. This method is overloaded, and the definition of the overloaded method is given here: public static MessageDigest getInstance(String algorithm, String provider) throws NoSuchAlgorithmException, NoSuchProviderException

This method generates a MessageDigest object implementing the specified algorithm. However, this algorithm is supplied by the specified provider. Therefore, the parameters to this method are the algorithm name and the provider name. The method throws NoSuchAlgorithmException if the algorithm is not supplied by the specified provider. If the specified provider is not available, the method throws NoSuchAlgorithmException.

The getProvider() Method The definition of this method is given here: public final Provider getProvider()

This method returns the provider of the message digest object.

The update() Method The definition of this method is given here: public void update(byte input)


Chapter 11

This method updates the digest by using the specified byte. This method is overloaded, and the definition of the overloaded method is given here: public void update(byte[] input, int offset, int len)

This method updates the digest by using the specified array of bytes, starting at the specified offset and continuing until the value specified by the len parameter. The definition of the overloaded method is given here: public void update(byte[] input)

This method updates the digest by using the specified array of bytes.

The digest() Method The definition of this method is given here: public byte[] digest()

This method completes the computation process of the digest. The message digest is reset to its initialized state after this method is invoked. This method is overloaded, and the definition of the overloaded method is given here: public it digest(byte[] buf, int offset, int len) throws DigestException

This method completes the message digest computation and stores the output in the byte array specified by the buf parameter. The number of bytes allotted in the buf array for storing the digest are marked by the offset and len parameters. The definition of the overloaded method is given here: public byte[] digest(byte[] input)

This method performs a final update on the digest by using the specified array of bytes. It then completes the digest computation. Therefore, this method first calls the update() method by passing the input array as a parameter. Finally, it calls the digest() method.

The toString() Method The definition of this method is given here: public String toString()

This method returns a String object conversion of the message digest object.

265

266

Part II


The isEqual() Method The definition of this method is given here: public static boolean isEqual(byte[] digesta, byte[] digestb)

This method determines whether two message digests are equal. It does a simple byte comparison and returns true if they are equal and false if not. The parameters passed to the method are the two digests that are to be compared.

The reset() Method The definition of this method is given here: public void reset()

This method resets the digest for further use.

The getAlgorithm() Method The definition of this method is given here: public final String getAlgorithm()

This method returns a string that represents the name of the message digest algorithm. The name should be a valid algorithm name.

The getDigestLength() Method The definition of this method is given here: public final int getDigestLength()

This method returns the length of the digest in bytes. It returns 0 if this implementation is not supported by the provider.

The clone() Method The definition of this method is given here: public Object clone() throws CloneNotSupportedException

This method returns a clone of the message digest if the implementation is cloneable; otherwise it throws CloneNotSupportedException. In the preceding sections, I’ve already discussed the Java API classes and interfaces for message digests. Now, let’s implement this knowledge. In the subsequent section, I’ll explain a Java program that computes and displays the message digests for three strings.


Chapter 11

Computing Message Digests in Java Let’s write a Java program that computes the message digests for three strings of which two are identical. This program introduces the use of the MessageDigest class. You’ll see in the output that the digest created for a specific string is always the same. Observe the following program listing: import java.io.*; import java.security.*; import sun.misc.*;

class ComputeMessageDigest { //Create a simple byte array containing the strings to be computed static String[] stringBuffer = {“Confidential”, “Top-Secret”, “Confidential”};

public static void main(String[] args) { //Compute a digest for the elements of the String array for(int i=0; i<stringBuffer.length; i++) digestString(i); }//end main

//This method computes and returns a digest for //the string at the specified position of the String array. static void digestString (int i){ try{ //Create a MessageDigest object implementing //the SHA algorithm provided by SUN MessageDigest md = MessageDigest.getInstance(“SHA”, “SUN”); //Update the digest by using the byte string //at the specified index position of the string array md.update(stringBuffer[i].getBytes()); //Complete the digest and save the result in String format String s = convertBase64(md.digest()); System.out.println(“\nInput string: System.out.println(“\nComputed Digest Value: } catch(Exception e){ System.out.println(e); System.exit(0);

“+stringBuffer[i]); “+s);

267

268

Part II


} } static String convertBase64(byte[] data){ BASE64Encoder encoder = new BASE64Encoder(); String encoded = encoder.encodeBuffer(data); return encoded; } }

The preceding code listing displays the output as in Figure 11-1. As seen in Figure 11-1, it is clear that the same strings have the same message digest value. Let’s observe the output of the ComputeMessageDigest.java program if the strings differ by a single character. Modify the second string in the array by removing the hyphen and replacing it by a space character as shown here: static String[] stringBuffer = {“Confidential”, “Top Secret”, “Confidential”};

The output of the modified ComputeMessageDigest.java program is shown in Figure 11-2. As seen in Figure 11-2, the change of a single character in an input string results in a considerable change in the computed message digest value. In the subsequent sections, I’ll discuss the DigestInputStream and DigestOutputStream classes in Java 2.

FIGURE 11-1 Output of the ComputeMessageDigest.java program


Chapter 11

FIGURE 11-2 Output of the modified ComputeMessageDigest.java program

The DigestInputStream Class Both the DigestInputStream and DigestOutputStream classes simplify the computation of message digests by reading or writing a sequence of bytes to streams. The DigestInputStream class is used to compute a message digest by reading the sequence of bytes from a stream. On the other hand, the DigestOutputStream class is used to compute a message digest on a sequence of bytes written to a stream. The DigestInputStream class is extended from the java.io.FilterInputStream class, and it is now a digest-calculating input filter. This stream updates the associated message digest. Therefore, to complete the message digest computation, you need to call one of the read() methods of the input stream, and then you need to call one of the digest() methods of the associated message digest. This input stream can be turned on and off. If the stream is on, a call to a read() method updates the message digest; otherwise the message digest is not updated. By default, the stream is on. Let’s discuss the methods of the DigestInputStream class.

The DigestInputStream Constructor The constructor definition is given here: public DigestInputStream(InputStream stream, MessageDigest digest)

This constructor creates a digest input stream by using the specified input stream and message digest.

269

270

Part II


The getMessageDigest() Method The method definition is given here: public MessageDigest getMessageDigest()

This method returns the message digest associated with the specified input stream.

The setMessageDigest() Method The method definition is given here: public void setMessageDigest(MessageDigest digest)

This method associates the message digest passed as a parameter with the specified input stream.

The read() Method The method definition is given here: public int read() throws IOException

This method reads the bytes from the input stream and blocks the stream until the bytes are read. If the digest function is on, the update() method, with the read byte as a parameter, is called on the message digest associated with this stream. This method returns the byte read from the stream. If an I/O error occurs, it throws IOException. This method is overloaded, and the definition of the overloaded method is given here: public int read(byte[] b, int off, int len) throws IOException

The method reads the bytes from the input stream, stores them in the byte array, and blocks the stream until the data is read. This method reads len bytes from the stream starting at the position specified by the off parameter and stores them in the b array. If the digest function is on, this method invokes the update() method and passes this array as a parameter.

The on() method The method definition is given here: public void on(boolean on)

This method turns the digest function on and off. By default, the digest function is on. When the function is on, a call to one of the read() methods results in updating


Chapter 11

of the message digest via the update() method. The message digest is not updated if the function is off. When the parameter on is true, the digest function is on. On the other hand, when the parameter is false, the digest function is off.

The toString() Method The method definition is given here: public String toString()

This method returns a string representation of the digest input stream and the associated message digest.

The DigestOutputStream Class The DigestOutputStream class is extended from the java.io.FilterOutputStream class, and it is now a digest-calculating output filter. This stream updates the associated message digest. Therefore, to complete message digest computation, you need to call one of the write() methods of the output stream, and then you need to call one of the digest() methods of the associated message digest. This output stream can be turned on and off. If the stream is on, a call to the write() methods results in updating the message digest; otherwise the message digest is not updated. By default, the stream is on. Let’s discuss the methods of the DigestOutputStream class.

The DigestOutputStream Constructor The constructor definition is given here: public DigestOutputStream(OutputStream stream, MessageDigest digest)

This method creates a digest output stream by using the output stream and message digest parameters.

The getMessageDigest() Method The method definition is given here: public MessageDigest getMessageDigest()

This method returns the message digest associated with the specified output stream.

271

272

Part II


The setMessageDigest() Method The method definition is given here: public void setMessageDigest(MessageDigest digest)

This method associates the message digest passed as a parameter with the output stream.

The write() Method The method definition is given here: public void write(int b) throws IOException

This method updates the message digest, if the digest function is on, and writes the specified byte to the output stream. It writes the bytes to the output stream even if the digest function is off. The method blocks the stream until the specified byte is written to the output stream. If an I/O error occurs, it throws IOException. This method is overloaded, and the definition of the overloaded method is given here: public void write(byte[] b, int off, int len) throws IOException

If the digest function is on, this method calls the update() method on the message digest. The write() method passes the subarray to the update() method. Then, this method writes the subarray bytes to the output stream. This holds true even when the digest function is off. The subarray belongs to the byte array, b. The length of this subarray is marked by the bytes contained in the array, b, starting at the offset off and continuing until the position marked by the len parameter.

The on() method The method definition is given here: public void on(boolean on)

This method turns the digest function on and off. By default, the digest function is on. When the function is on, a call to one of the write() methods results in updating the message digest via the update() method. The message digest is not updated if the function is off. When the parameter on is true, the digest function is on. On the other hand, when the parameter is false, the digest function is off.

The toString() Method The method definition is given here: public String toString()


Chapter 11

This method returns a string representation of the digest output stream and the associated message digest.

Using Digest Streams You need to create a MessageDigest object before working with digest streams. Once the object is created, pass it as a parameter to the DigestInputStream and DigestOutputStream constructors to create a digest stream object. You can use these streams for input and output and to retrieve the updated MessageDigest object. You can retrieve the final value by calling the MessageDigest.digest() method. Let’s write a Java program that uses both the DigestInputStream and DigestOutputStream classes. This program defines a useOutputStream() method that creates a MessageDigest object and a FileOutputStream object. The FileOutputStream object writes to the file, finalresult.txt. Finally, a DigestOutputStream object is created by using the MessageDigest and FileOutputStream objects. The write() method of this stream object is used to write the specified string to the output stream. Finally, the message digest is updated and retrieved from the output stream by using the digest() method. The program also contains a useInputStream() method that operates in a similar manner as the useOutputStream() method. The only exception is that this method reads the data stored in the finalresult.txt file and then computes the digest value based on the byte data it has read. Now, let’s observe the program listing for the previously discussed program: import java.security.*; import java.io.*; import sun.misc.*; public class UseDigestStreams{ //Create a sample string that will be written or read to the digest streams static String original = “This is a test of using digest streams”; public static void main(String[] args) { useOutputStream(); useInputStream(); } static void useOutputStream(){ try{ MessageDigest md = MessageDigest.getInstance(“MD5”, “SUN”); FileOutputStream fos = new FileOutputStream(“finalresult.txt”);

273

274

Part II


DigestOutputStream dos = new DigestOutputStream(fos,md); byte[] b = original.getBytes(); dos.write(b,0,b.length); md = dos.getMessageDigest(); String s = convertBase64(md.digest()); System.out.println(“\nOutput string: System.out.println(“\nComputed Digest Value:

“+original); “+s);

} catch(Exception e){ System.out.println(e); System.exit(0); } } static void useInputStream(){ try{ MessageDigest md = MessageDigest.getInstance(“MD5”, “SUN”); FileInputStream fis = new FileInputStream(“finalresult.txt”); DigestInputStream dis = new DigestInputStream(fis,md); byte[] b = new byte[original.length()]; dis.read(b,0,original.length()); md = dis.getMessageDigest(); String s = convertBase64(md.digest()); System.out.println(“\nInput string: System.out.println(“\nComputed Digest Value:

“+original); “+s);

} catch(Exception e){ System.out.println(e); System.exit(0); } } static String convertBase64(byte[] data){ BASE64Encoder encoder = new BASE64Encoder(); String encoded = encoder.encodeBuffer(data); return encoded; } }

The preceding program displays the following output at the command-line, as shown in Figure 11-3.


Chapter 11

FIGURE 11-3 Output of the UseDigestStreams.java program

The original string is also written to and read from the finalresults.txt file. You can open and check the contents of this file.

Message Authentication Codes (MACs) Message Authentication Codes (MACs) are message digests that are computed by using secret key cryptography. These are necessary when you need to detect the changes made to a message when it is transferred over an unsafe network connection. Let’s consider an example. Suppose Susan wants to transfer a message to Marc over an unsafe network connection. Susan will first compute the message digest of the message and send it along with the message to Marc. During the transmission of the message, Robert traces the message and the message digest and makes changes first to the message and then to the message digest. This modified message and message digest reach Marc. However, he is unable to detect the changes because he checks the message digest and verifies that it is the correct one as per the message. Now, how is the previous scenario going to be any different by the use of message authentication codes? MACs use a cryptographic key while calculating the associated message digest of a message. Therefore, any message that uses MACs for the calculation of message digests cannot be modified, retransmitted, or deciphered. Therefore, in the previous scenario, consider that Marc receives the MAC and the message, which have been replaced by Robert. Marc uses the secret key in the MAC to determine that the MAC is not the correct authentication code that was sent by Susan. This secret key is shared by only Marc and Susan. Without knowing this key, Robert cannot make changes to the message or the MAC. The support for message authentication codes is provided by the MacSpi and Mac classes in Java 2. I’ll discuss these classes in detail in the subsequent sections.

275

276

Part II


The MacSpi Class This class defines the Service Provider Interface (SPI) for the Mac class. The methods in this class are abstract and must be implemented by each cryptographic service provider who wants to supply the implementation of a particular MAC algorithm. The methods of the MacSpi class are defined in the subsequent sections.

The engineGetMacLength() Method The method definition is given here: protected abstract int engineGetMacLength()

This method returns the length of the Mac in bytes.

The engineInit() Method The method definition is given here: protected abstract void engineInit(Key key, AlgorithmParameterSpec params) throws InvalidKeyException, InvalidAlgorithmParameterException

This method initializes the MAC with the specified secret key and algorithm parameters. It throws InvalidKeyException if the given key is inappropriate for initializing the MAC. It throws InvalidAlgorithmParameterException if the given algorithm parameters are inappropriate for the MAC.

The engineUpdate() Method The method definition is given here: protected abstract void engineUpdate(byte input)

This method processes the bytes specified by the input parameter. This method is overloaded, and the definition of the overloaded method is given here: protected abstract void engineUpdate(byte[] input, int offset, int len)

This method processes the bytes specified by the len parameter starting at the position marked by offset.

The engineDoFinal() Method The method definition is given here: protected abstract byte[] engineDoFinal()


Chapter 11

This method completes the MAC computation and resets the MAC for further use. It maintains the secret key that was used to initialize the MAC.

The engineReset() Method The method definition is given here: protected abstract void engineReset()

This method resets the MAC for further use and maintains the secret key by which the MAC was initialized.

The clone() Method The method definition is given here: public Object clone() throws CloneNotSupportedException

This method is similar to the clone() method discussed in the preceding section.

The Mac Class The Mac class provides the functionality of a MAC algorithm. HMAC is a MAC mechanism that is based on cryptographic hash functions such as MD5 or SHA-1 in combination with a secret shared key. Let’s discuss the methods of this class in subsequent sections.

The Mac() Constructor The constructor definition is given here: protected Mac(MacSpi macSpi, Provider provider, String algorithm)

This constructor creates a Mac object as per the MacSpi object, provider name, and algorithm provided to it as parameters.

The getAlgorithm() Method The method definition is given here: public final String getAlgorithm()

This method returns the algorithm name of the specified Mac object. This is the same algorithm that is used when a Mac object is created.

277

278

Part II


The getInstance() Method The method definition is given here: public static final Mac getInstance(String algorithm) throws NoSuchAlgorithmException

This method generates a Mac object by using the specified MAC algorithm. The default provider package is checked for the implementation of the requested MAC algorithm. If the algorithm is not available in the default provider package, the other provider packages are searched. If the algorithm is not available in any other provider package as well, NoSuchAlgorithmException is thrown. This method is overloaded, and the definition of the overloaded method is given here: public static final Mac getInstance(String algorithm, String provider) throws NoSuchAlgorithmException, NoSuchProviderException

This method generates a Mac object by using the specified MAC algorithm and the provider name that are passed as parameters. If the specified algorithm is not available from the specified provider, NoSuchAlgorithmException is thrown. If the specified provider is not configured, NoSuchProviderException is thrown. Another overloaded method definition is given here: public static final Mac getInstance(String algorithm, Provider provider) throws NoSuchAlgorithmException

This method also generates a Mac object by using the specified MAC algorithm and the provider that are passed as parameters. The difference is that the provider need not be registered. Therefore, the provider parameter is a Provider object rather than a String object as in the earlier method definition.

The getProvider() Method The method definition is given here: public final Provider getProvider()

This method returns the provider of the specified Mac object.

The getMacLength() Method The method definition is given here: public final int getMacLength()


Chapter 11

This method returns the length of the Mac in bytes.

The init() Method The method definition is given here: public final void init(Key key) throws InvalidKeyException

This method initializes the specified Mac object with the key parameter. This method is overloaded, and the definition of the overloaded method is given here: public final void init(Key key, AlgorithmParameterSpec params) throws InvalidKeyException, InvalidAlgorithmParameterException

This method initializes the specified Mac object by using the key and algorithm parameters. If either of the given key or algorithm parameters is inappropriate for the MAC, InvalidKeyException or InvalidAlgorithmParameterException is thrown respectively.

The update() Method The method definition is given here: public final void update(byte input) throws IllegalStateException

This method processes the bytes specified by the input parameter. This method is overloaded, and the definition of the overloaded method is given here: public final void update(byte[] input) throws IllegalStateException

This method processes the given array of bytes. Another overloaded method definition is given here: public final void update(byte[] input, int offset, int len) throws IllegalStateException

This method processes the bytes specified by the len parameter starting at the offset position in the specified input byte array.

The doFinal() Method The method definition is given here: public final byte[] doFinal() throws IllegalStateException

279

280

Part II


This method finishes the MAC process. It resets the Mac object to the state when it was initialized by the init() methods. Therefore, the Mac object can generate another Mac from the same key by using the update() and doFinal() methods. If you want to use another key with this Mac object, it needs to be reinitialized by using the init() methods. This method returns the result generated by the MAC. It throws IllegalStateException if the Mac object is not initialized. This method is overloaded, and the definition of the overloaded method is given here: public final void doFinal(byte[] output, int outOffset) throws ShortBufferException, IllegalStateException

The operation of this overloaded method is similar to that of the preceding method. The only exception is that the output of the MAC operation is stored in a byte array starting from the offset position marked by the outOffset parameter. This method throws ShortBufferException in addition to IllegalStateException if the output buffer is too small to contain the final result. Another overloaded method definition is given here: public final byte[] doFinal(byte[] input) throws IllegalStateException

The only difference from the other methods is that it processes the given array of bytes and then completes the MAC operation. The input byte array is passed as a parameter.

The reset() Method The method definition is given here: public final void reset()

This method resets the specified Mac object to a state when it was initialized by the init() method. Therefore, the Mac object can generate another MAC from the same key by using the update() and doFinal() methods. If you want to use another key with this Mac object, it needs to be reinitialized by using the init() method. The clone() method of this class is similar to the method discussed in the preceding classes. As seen in the preceding sections, message digests let you know if your messages have been altered or replaced. However, when you are at the receiving end, you cannot make out whether the message and the message digest reaching you are those dispatched by the sender. This is where the importance of digital signatures comes in. I’ll discuss digital signatures in the subsequent sections.


Chapter 11

Digital Signatures Digital signatures are used to authenticate data and check it for integrity. They provide assurance that the message has not been tampered with and originates from the signing authority. Digital signatures are useful when you need to distribute software or documentation as they prevent any forgery attempts. A digital signature is computed from a sequence of bytes by using a secret key. The person having this secret key can authenticate the contents of a specified message. In digital signatures, key pairs are used for encryption algorithms. The public key is used for decryption, and the private key is used for encryption. Digital signatures have the following properties: ◆ They cannot be forged because the signers use their private keys to sign

messages and these keys are kept secret. ◆ Once the signers have signed a message that has been delivered to the receiving end, they cannot claim they have not signed the specified message. This is called non-repudiation. ◆ The signature can be verified by anyone because the public key is readily available. ◆ A signed message is sealed and cannot be tampered with without nullifying the signature. In the subsequent section, let’s discuss how these digital signatures are actually implemented in Java 2.

Classes and Interfaces for Digital Signatures In this section, I’ll discuss the classes and interface support provided in the java.security package for digital signatures. These classes include: ◆ SignatureSpi ◆ Signature

I’ll discuss these classes in detail in the subsequent sections.

The SignatureSpi Class This class defines the SPI interface for the Signature class. The abstract methods in this class are implemented by using a cryptographic service provider that supplies the implementation of a particular signature algorithm. Let’s discuss these methods in detail in the subsequent sections.

281

282

Part II


The engineInitVerify() Method The method definition is given here: protected abstract void engineInitVerify(PublicKey publicKey) throws InvalidKeyException

This method initializes the specified signature object with the public key that is used for verification purposes. This public key is passed as a parameter to the method. This is the public key of the identity whose signature is going to be verified. This method throws InvalidKeyException if the key is not encoded properly.

The engineInitSign() Method The method definition is given here: protected abstract void engineInitSign(PrivateKey privateKey) throws InvalidKeyException

This method initializes the signature object with the specified private key for signing purposes. The private key of the identity whose signature will be generated is passed as a parameter to this method. This method throws InvalidKeyException if the key is not encoded properly. This method is overloaded, and the definition of the overloaded method is given here: protected void engineInitSign(PrivateKey privateKey, SecureRandom random) throws InvalidKeyException

This method initializes the signature object with the specified private key and the source of randomness for signing purposes. The specified private key and the source of randomness are passed as parameters to this method.

The engineUpdate() Method The method definition is given here: protected abstract void engineUpdate(byte b) throws SignatureException

This method updates the data that is to be signed and verified by using the byte passed to it as a parameter. If the engine is not initialized properly, the method throws SignatureException. This method is overloaded, and the definition of the overloaded method is given here: protected abstract void engineUpdate(byte[] b, int off, int len) throws SignatureException


Chapter 11

This method updates the data to be signed or verified by using the array of bytes passed as a parameter. The len parameter defines the number of bytes to use starting from the off parameter.

The engineSign() Method The method definition is given here: protected abstract byte[] engineSign() throws SignatureException

This method returns the signature bytes of the updated data. These bytes are a result of the signing operation. The format of the signature is judged by the associated scheme. If the engine is not initialized properly, the method throws SignatureException. This method is overloaded, and the definition of the overloaded method is given here: protected int engineSign(byte[] outbuf, int offset, int len) throws SignatureException

This method completes the signature operation and stores the resulting bytes in the output buffer specified by the outbuf parameter starting at the offset position and continuing until the value specified by the len parameter. After this, the signature implementation is reset to its initial state. This implementation can be reused to generate more signatures with similar private keys. If the value of the len parameter is less than the actual signature length, the method throws SignatureException.

The engineVerify() Method The method definition is given here: protected abstract boolean engineVerify(byte[] sigBytes) throws SignatureException

This method verifies the signature that is passed to it as a parameter. This method returns true if the signature is verified; otherwise it returns false. If the engine is not initialized properly or the signature bytes are not properly encoded, the method throws SignatureException.

The engineSetParameter() Method The method definition is given here: protected abstract void engineSetParameter(String param, Object value) throws InvalidParameterException

283

284

Part II


This method provides a way of setting the various parameters of the signature object. These parameters could be any settable parameters for the algorithm, such as a source or random bits for signature generation or an indication to perform a computation. Therefore, this method sets the specified algorithm parameter to the specified value, both of which are passed as parameters. If the parameter is an invalid format for the signature algorithm engine or the parameter is already set, this method throws InvalidParameterException. This method is overloaded, and the definition of the overloaded method is given here: protected void engineSetParameter(AlgorithmParameterSpec params) throws InvalidAlgorithmParameterException

This overloaded method initializes the signature engine with the specified parameter set. This method may be overridden by a provider, which sets the algorithm parameters by using the params parameter. If this parameter is invalid, the method throws InvalidAlgorithmParameterException.

The engineGetParameter() Method The method definition is given here: protected abstract Object engineGetParameter(String param) throws InvalidParameterException

This method returns an object that represents the specified algorithm parameter value. If the parameter is invalid for the particular engine, the method throws InvalidParameterException. The clone() method in this class is similar to the method discussed in the preceding sections.

The Signature Class The Signature class provides digital signature functionality to Java applications. The Digital Signature Algorithm (DSA) can be either the NIST standard DSA or a DSA with SHA-1. The NIST standard DSA is a standard that specifies a DSA appropriate for applications requiring a digital rather than written signature. The signing algorithms can be specified as SHA1withDSA, MD5withRSA, or SHA1withRSA. Because there is no default name for the signature algorithms, a name needs to be provided. The Signature class provides algorithms that are implementation-independent. You can also request for a particular algorithm from the list of providers. The Signature object is used to generate and verify digital signatures. The signature algorithm object can be


Chapter 11

requested by providing either the algorithm name or both the algorithm and provider names. The life cycle of a Signature object generally consists of three major phases. First, you need to initialize the Signature object with the public key or private key by using the various init() methods. The public key is used when you want to initialize the signature for verification, whereas the private key is used to initialize the signature for signing purposes. The second phase is updating the Signature object depending on the type of initialization by using the various update() methods. The final phase is signing or verifying a signature on the updated bytes. The Signature class extends from the SignatureSpi class. The methods in the Signature class are intended for application developers, whereas the methods in the SignatureSpi class are intended for cryptographic service providers. Let’s discuss the various methods in this class in the subsequent sections.

The Signature() Constructor The definition of this constructor is given here: protected Signature(String algorithm)

This constructor creates a Signature object by using the algorithm passed as a parameter.

The getInstance() Method The definition of this method is given here: public static Signature getInstance(String algorithm) throws NoSuchAlgorithmException

This method returns a Signature object that implements the specified algorithm. First, the default provider package searches for the implementation of the specified algorithm. If the implementation is found, the Signature object is returned; otherwise the algorithm implementation is searched for in the other provider packages. If the algorithm is still not found, NoSuchAlgorithmException is raised. This method is overloaded, and the definition of the overloaded method is given here: public static Signature getInstance(String algorithm, String provider) throws NoSuchAlgorithmException, NoSuchProviderException

This method generates a Signature object based on the specified algorithm supplied by the specified provider. Both the algorithm and the provider name are passed as parameters to this method. The object is created only if the specified provider supplies

285

286

Part II


such an algorithm. If the algorithm is not available in the specified provider package, the method raises NoSuchAlgorithmException. On the other hand, if the specified provider is not available in the caller’s environment, the method raises NoSuchProviderException.

The getProvider() Method The definition of this method is given here: public final Provider getProvider()

The method returns the provider of the specified Signature object.

The initVerify() Method The definition of this method is given here: public final void initVerify(PublicKey publicKey) throws InvalidKeyException

This method initializes the object for verification by using the public key of the identity whose signature is to be verified. If the supplied public key is invalid, the method throws InvalidKeyException.

The initSign() Method The definition of this method is given here: public final void initSign(PrivateKey privateKey) throws InvalidKeyException

This method initializes the object for signing by using the specified private key of the identity whose signature is to be created. If the given key is invalid, the method throws InvalidKeyException. This method is overloaded, and the definition of the overloaded method is given here: public final void initSign(PrivateKey privateKey, SecureRandom random) throws InvalidKeyException

The method is similar to the preceding method with one exception that the source of randomness is also passed as a parameter.

The sign() Method The definition of this method is given here: public final byte[] sign() throws SignatureException


Chapter 11

This method returns the signature bytes of updated data. The final signature format depends on the associated signature scheme. The signature object is reset to the state when it was initialized. The object is now ready to generate another signature from the same signer by making calls to the update() and sign() methods. If the signature object is not initialized properly, the method throws SignatureException. This method is overloaded, and the definition of the overloaded method is given here: public final int sign(byte[] outbuf, int offset, int len) throws SignatureException

This method finalizes the signature operation and stores the signature bytes in the specified output buffer, outbuf. The number of bytes allotted in this buffer for the signature is marked by the len parameter starting at the offset position.

The verify() Method The definition of this method is given here: public final boolean verify(byte[] signature) throws SignatureException

This method verifies the signature passed as a parameter. This method resets the signature object to its initialized state before verification. The object can now verify more signatures from the same identity.

The update() Method The method definition is given here: public final void update(byte b) throws SignatureException

This method updates the data that is to be signed and verified by using the byte passed to it as a parameter. If the engine is not initialized properly, the method throws SignatureException. This method is overloaded, and the definition of the overloaded method is given here: public final void update(byte[] data) throws SignatureException

This method updates the data to be signed or verified by using the array of bytes that is passed to it as a parameter. There is another overloaded method that is defined here: protected abstract void engineUpdate(byte[] b, int off, int len) throws SignatureException

287

288

Part II


This method updates the data to be signed or verified by using the array of bytes passed as a parameter. The len parameter defines the number of bytes to use starting from the off parameter.

The getAlgorithm() Method The method definition is given here: public final String getAlgorithm()

This method returns the algorithm name of the specified Signature object.

The setParameter() Method The method definition is given here: public final void setParameter(String param, Object value) throws InvalidParameterException

This method provides a way of setting various parameters of the Signature object. These parameters could be any settable parameters for the algorithm such as a source or random bits for signature generation or an indication to perform a computation. Therefore, this method sets the specified algorithm parameter to the specified value, both of which are passed as parameters. If the parameter is an invalid format for the signature algorithm engine, or the parameter is already set, this method throws InvalidParameterException. This method is overloaded, and the definition of the overloaded method is given here: public final void setParameter(AlgorithmParameterSpec params) throws InvalidAlgorithmParameterException

This overloaded method initializes the Signature object with the specified parameter set. This method may be overridden by a provider, which sets the algorithm parameters by using the params parameter. If this parameter is invalid, the method throws InvalidAlgorithmParameterException.

The getParameter() Method The method definition is given here: public final Object getParameter(String param) throws InvalidParameterException

This method returns an object that represents the specified algorithm parameter value. If the parameter is invalid for the particular engine, the method throws InvalidParameterException.


Chapter 11

Using the Signature Class to Create and Verify Signatures In this section, I’ll create a Java program that uses the Signature object to create and verify signatures. This program takes the original message string during runtime at the command prompt. It uses the NIST DSA algorithm for signing and verification purposes. The program logic is divided into four methods. The generateKeyPair() method creates a KeyPairGenerator object for the DSA. It then generates a private and public key pair. The createSign() method creates a Signature object by using the getInstance() method. It then initializes it by using the initSign() method. For signing, it uses the private key generated by the generateKeyPair() method. It then updates the signature by using the update() method and creates the final signature by using the sign() method. The verifySign() method verifies the signature returned by the createSign() method. It does this by using the public key of the generated KeyPair object. The convertBase64() method converts the public and private key data to string format. It does this for the signature generated. The preceding methods are collated in the following UseDigSign.java program listing. import java.io.*; import java.security.*; import sun.misc.*;

public class UseDigSign{

public static void main(String[] args) { //Defining the algorithm used for creating the signature String algo = “DSA”; //Generating a key pair KeyPair kp = generateKeyPair(algo); // Generating a digital signature for the original message string that // is a command-line argument while executing the program byte[] sig = createSign(args[0], algo, kp); //Verifying the digital signature verifySign(args[0], algo, sig, kp.getPublic()); }

289

290

Part II


static KeyPair generateKeyPair(String algo){ try{ KeyPairGenerator kpg = KeyPairGenerator.getInstance(algo); System.out.println(“Key pair is generated”); KeyPair kp = kpg.genKeyPair(); return kp; }catch(Exception e){ System.out.println(e); } return null; } static byte[] createSign(String s, String algo, KeyPair kp){ try{ Signature mySign = Signature.getInstance(algo); PrivateKey prik = kp.getPrivate(); PublicKey

pubk = kp.getPublic();

mySign.initSign(prik); System.out.println(“\nSignature is generated”); mySign.update(s.getBytes()); byte[] b = mySign.sign(); System.out.println(“\nOriginal Message:

“+s);

System.out.println(“\nPrivate key:

“+

convertBase64(prik.getEncoded())); System.out.println(“\nPublic key :

“+

convertBase64(pubk.getEncoded())); System.out.println(“\nSignature

:

“+convertBase64(b));

return b; }catch(Exception e){ System.out.println(e); } return null; } static void verifySign(String s, String algo, byte[] sig, PublicKey pubk){ try{ Signature mySign = Signature.getInstance(algo); System.out.println(“\nSignature is being verified”); mySign.initVerify(pubk);


Chapter 11

mySign.update(s.getBytes()); if(mySign.verify(sig)) System.out.println(“\nSignature is verified sucessfully”); else System.out.println(“\nSignature not verified”); }catch(Exception e){ System.out.println(e); } } static String convertBase64(byte[] data){ BASE64Encoder encoder = new BASE64Encoder(); String encoded = encoder.encodeBuffer(data); return encoded; } }

The output of the UseDigSign.java program is shown in Figure 11-4.

FIGURE 11-4 Output of the UseDigSign.java program

291

292

Part II


As can be seen in the preceding output, the message is entered at the command-line prompt. The public key, private key, and signature are encoded in Base 64 format. Finally, the signature is verified as well.

Summary In this chapter, I discussed the concepts of a message digest and a digital signature in detail. I started by discussing what message digests are. I also discussed the Base 64 encoding format. Then, I discussed the implementation of message digests in Java 2. This included the built-in classes for message digests, namely MessageDigestSpi, MessageDigest, DigestInputStream, and DigestOutputStream. Next, I discussed Message Authentication Codes (MACs). I discussed the MacSpi and Mac classes in Java2 that implement MACs. Then, I discussed digital signatures in general. Finally, I discussed the implementation of digital signatures by the SignatureSpi and Signature classes.

Check Your Understanding Multiple Choice Questions 1. Which of the following statements is/are true? a. Susan computes similar message digests for two different messages. b. Marc gets different message digests every time he computes them for a message. c. Robert cannot verify a digital signature because he cannot access the public key. d. Caryl computes the same message digest for a message multiple times. 2. To generate a MessageDigest object where any provider can supply the given algorithm, which of the following statements would you use? a. public static MessageDigest getInstance(String algorithm) throws NoSuchAlgorithmException

b. public static MessageDigest getInstance(String algorithm, String provider) throws NoSuchAlgorithmException, NoSuchProviderException


Chapter 11

c. public static MessageDigest getInstance(“MD5”, “SUN”) d. public static MessageDigest getInstance(“SHA-1”, “SUN”) 3. Which of the following classes can you use to simplify the computation of message digests? a. DigestInputStream b. Mac c. MacSpi d. DigestOutputStream 4. John succeeds in replacing the message digest and the message being sent from Caryl to Robert over an insecure network connection. Robert does not know that he has received a tampered message because both the message and the message digest match. How can Robert authenticate and check the integrity of the message sent by Caryl? Select the practically feasible options from these: a. By ringing up Caryl and mapping the message and message digest b. By using MACs c. By Caryl digitally signing the message d. By Caryl not sending the message until she finds a secure network connection 5. The algorithm used for signing messages needs a source or random bits for signature generation or an indication to perform a computation. Which of the following methods can you use to make this possible? a. setParameter() b. setRandomBit() c. update() d. getParameter()

Short Questions 1. Explain the process of creating and signing digital signatures. 2. Explain the role of the DigestInputStream and DigestOutputStream classes. 3. Compute the message digests for the strings “Private Data “ and “Secure Data”.

293

294

Part II


Answers Multiple Choice Answers 1. d. Similar message digests cannot be generated for different messages. The value of the message digest remains the same even though it is calculated multiple times. 2. a. In the remaining statements, the algorithm is supplied by the specified provider. 3. a and d. Both the DigestInputStream and DigestOutputStream classes simplify the computation of message digests by reading or writing a sequence of bytes to streams. 4. b and c. MAC and digital signatures help in authenticating and checking integrity of messages passed across an insecure network connection. 5. a and d. The setParameter method provides a way of setting the Signature object’s parameters. These parameters could be any settable parameters for the algorithm such as a source or random bits for signature generation or an indication to perform a computation. The getParameter() method returns an object that represents the specified algorithm parameter value.

Short Answers 1. The life cycle of a Signature object generally consists of three major phases. First, you need to initialize the Signature object with the public key or private key by using the various init() methods. The public key is used when you want to initialize the signature for verification, whereas the private key is used to initialize the signature for signing purposes. The second phase is updating the Signature object depending on the type of initialization by using the various update() methods. The final phase is signing or verifying a signature on the updated bytes. 2. Both the DigestInputStream and DigestOutputStream classes simplify the computation of message digests by reading or writing a sequence of bytes to streams. The DigestInputStream class is used to compute a message digest by reading the sequence of bytes from a stream. On the other hand, the DigestOutputStream class is used to compute a message digest on a sequence of bytes written to a stream.


Chapter 11

3. The following code listing illustrates a Java program that computes the message digests for the strings, “Private Data” and “Secure Data”. This program uses the MessageDigest class: import java.io.*; import java.security.*; import sun.misc.*; class ComputeMessageDigest { //Create a simple byte array containing the strings to be computed static String[] stringBuffer = {“Private Data”, “Secure Data”}; public static void main(String[] args) { //Compute a digest for the elements of the String array for(int i=0; i<stringBuffer.length; i++) digestString(i); }//end main

//This method computes and returns a digest for an //incoming string array static void digestString (int i){ try{ //Create a MessageDigest object implementing the SHA //algorithm provided by SUN MessageDigest md = MessageDigest.getInstance(“SHA”, “SUN”); //Update the digest by using the input byte string md.update(stringBuffer[i].getBytes()); //Complete the digest and save the result in String format String s = convertBase64(md.digest()); System.out.println(“\nInput string:

“+stringBuffer[i]);

System.out.println(“\nComputed Digest Value: } catch(Exception e){ System.out.println(e); System.exit(0); } }

“+s);

295

296

Part II


static String convertBase64(byte[] data){ BASE64Encoder encoder = new BASE64Encoder(); String encoded = encoder.encodeBuffer(data); return encoded; } }

Chapter 12 An Introduction to Cryptography

’ ve already discussed cryptographic concepts in brief in Chapter 1, “Security: An Overview”. In Java 2, cryptographic functions are supported by APIs provided by Java Cryptography Architecture ( JCA) and Java Cryptography Extension ( JCE). In this chapter, I’ll discuss these APIs in detail. I’ll also discuss how these APIs help in implementing cryptographic functions.

I

The Need for Cryptography In earlier times, cryptography was considered the study of algorithms and protocols that help in secure message transmission and storage. However, presently, cryptography is not limited to just messages. It can also be used with files or byte streams. Cryptography preserves the integrity of data by implementing secure transfers. It also supports authentication and non-repudiation. Let’s review the meaning of these terms before proceeding further. Authentication refers to the process of proving the identity of a user. For example, a server needs to identify the client who is placing a request before processing that request. There are various authentication measures that you can use, such as password authentication, using encrypted keys or smart cards, and using biometric technique, such as voice recognition. When data is transferred, you must check the integrity of the data after transfer to check whether the data has been altered. You can also encrypt sensitive information before transferring it over an unsecured connection. Non-repudiation is related to authentication and refers to the ability to prove that a user with a particular identity performs a specified action. A non-repudiation service performs this task by establishing accountability by the user for performing the specified task. All these requirements must be fulfilled for implementing cryptography. These requirements can be approached by using encryption, decryption, and digital signatures. Let’s discuss these in detail. The terms encryption and cryptography are often confused with each other. Encryption is just one supporting feature of cryptography. Encryption refers to the process of coding data so that its confidentiality can be maintained. Only the intended person can decipher this coded data. In encryption, the coded data is also referred to as cipher text and the key used to produce this cipher text is called the cryptographic key. Ciphers

AN INTRODUCTION TO CRYPTOGRAPHY

Chapter 12

are the algorithms used to convert plain text to cipher text. Decryption is the reverse of the encryption process. For decryption, you need the cipher text and the cryptographic key to decode the coded data to the original plain text. There are two types of keys that perform the encryption process—symmetric and asymmetric keys. In symmetric key encryption, both encryption and decryption are performed by using the same cryptographic or secret key. Therefore, symmetric keys help in maintaining confidentiality of data if the shared secret key is not passed to another identity. On the other hand, asymmetric keys have different values at either end. One end can use a public key that can be shared with everyone whereas another end uses a private key that cannot be shared. If the public key is used while decrypting data, no confidentiality is maintained because anyone can decipher the data. However, because a private key is used for encrypting, the data has the identity of the user who signed it. On the other hand, if the private key is used to decipher data, confidentiality is being maintained because only the user possessing the private key can decipher the data. But, there is no identity of the data at the encrypting end because any user possessing the public key can sign the data. Let’s discuss the algorithms supported by both symmetric and asymmetric keys in the subsequent sections.

Symmetric Key Algorithms Although symmetric key usage for encryption provides very powerful cryptographic features, it is unsafe to use symmetric keys. The reason behind this is that because the same key is used at both ends it becomes difficult to share this key. There is possibility of the key being misused by an attacker. Therefore, the secret key is transferred by using asymmetric algorithms that maintain the confidentiality of the key. This secret key is then used for all the operations being performed during encryption. The main symmetric key algorithms are Data Encryption Standard (DES), which uses a 56-bit secret key and Triple-DES, which strengthens the DES algorithm by performing the algorithm three times with three different keys. Let’s discuss the DES algorithm in brief. Refer to Figure 12-1 to understand the symmetric key encryption process.

The Data Encryption Standard (DES) Initially, DES was known as the standard encryption algorithm for protecting information in the United States. However, after a short span of time, various attacks while using DES were listed. These attacks concluded that cracking DES was successful. However, DES is still being used because it is cost-effective. However, now it has been strengthened by the use of Triple-DES where DES is implemented three times with three different keys. DES is used in cases where the cost of cracking DES is

299

300

Part II


FIGURE 12-1 The symmetric key encryption process

more than the actual cost of the information decoded. For example, I’ve encoded some official information using DES. You spend a lot of money and resources to crack DES and end up with information that was of no use to you. Therefore, the cost of cracking DES was more than the actual cost of the information decoded because the information was of no use to you.

NOTE To read more about the DES standard, you can access the http://www.itl.nist.gov/fipspubs/fip46-2.htm link.

Asymmetric Key Algorithms I’ve already discussed that asymmetric keys when used for encryption provide confidentiality. Asymmetric key algorithms are more successful as compared to symmetric key algorithms. They are also called public key algorithms. Asymmetric keys are more secure because they permit you to posses a private key that cannot be distributed to other users in an encryption session. On the other hand, you can distribute the public


Chapter 12

key to people who want to use your key to encrypt data or need to verify the identity of an encrypted message. Encrypting data by using a private key is called the signature of the signer because only the user possessing the key can create such a bit pattern. The public key algorithms should be designed such that they render it infeasible to compute the private key from the public key in an asymmetric cryptographic scenario. Certain asymmetric key algorithms are Digital Signature Algorithm (DSA) and Rivest Shamir Adleman (RSA) algorithm. The RSA algorithm is the most famous public key algorithm because it is used both for creating digital signatures and in encryption. RSA is secure because its functioning depends on large numbers that cannot be deciphered easily. When you use RSA, you can release your public keys to the remaining users. Then, another person can send you an encrypted message by using your public key. Only you can decrypt this message because only you possess the private key that can be used to decipher the coded message. This is an advantage as compared to symmetric keys where you have to share the secret key. In RSA and other asymmetric key algorithms, you do not need to share your secret key for decoding the data. The only disadvantage of using asymmetric key algorithms is that they are very slow as compared to symmetric key algorithms. Therefore, they are used with symmetric key algorithms to transfer the secret key across the two ends in an encryption scenario. Refer to Figure 12-2 to understand the asymmetric key encryption process.

FIGURE 12-2 The asymmetric key encryption process

301

302

Part II


Digital Certificates Digital signatures perform non-repudiation of messages by authenticating that the respective message actually belongs to the identity (user or organization) that signs it. However, how can you determine that the public key used by the signers actually belongs to them? Digital certificates help you to authenticate this information. Digital certificates certify the value of the signer’s public key. Digital certificates are messages that are signed by a certification authority (CA). CA is an entity that verifies that the signers are original and use their public key along with the public-key encryption algorithm.

Java Cryptography Architecture (JCA) JCA was first introduced in the Java platform with the release of Java 1.1. JCA includes the APIs that support cryptographic functionality in Java. JCA provides support to protect data that is communicated or stored for integrity. It also provides support for generating keys and certificates that are used to identify data sources. However, JCA is not useful when you need to encrypt data for communication or storage purposes. In such cases, where you require confidentiality in cryptographic functions, you can use JCE. JCE is shipped separately from the Java 2 platform because of U.S. export restrictions. However, in case of JCA there are no such restrictions. JCA and JCE together form the core and platform-independent architecture that supports all cryptographic APIs in Java. JCA is both implementation and algorithm independent. Therefore, users can access cryptographic functions without knowing the implementation or algorithm that supports the particular function. If complete implementation-independence is not possible, JCA provides developers with freedom to specify the desired implementation. On the other hand, if complete algorithm-independence is not possible, users can use the standard algorithm-specific APIs in JCA. Implementation-independence can be acquired by using a provider-based architecture, whereas algorithm-independence can be achieved by defining algorithms also called as cryptographic engines. The classes that provide the functionality of these cryptographic engines are called engine classes. Multiple implementations and algorithms are supported by a single encryption session. Therefore, there should be interoperability between different implementations and algorithms so that a signature generated by a specific provider can be verified by another provider implementation. Algorithms are extensible so that a new algorithm supported by an engine class can be easily added to the architecture.

Cryptographic Engines and Algorithms There are different engine classes in JCA for providing functionality to different algorithm types. A Java class is defined for each engine class in JCA. For example, the


Chapter 12

Signature engine class is used to sign and verify digital signature. The different cryp-

tographic engine types supported by JCA are: ◆ The KeyPairGenerator class generates public and private key pairs for a

specified algorithm. ◆ The MessageDigest class creates and verifies message digests. ◆ The Signature class creates and verifies digital signatures. ◆ The KeyStore class modifies the information stored in the keystore data-

base. ◆ The SecureRandom class generates random numbers. ◆ The AlgorithmParameters class generates crypto algorithm parameters.

An engine class provides the functionality to implement an interface for a specific algorithm type. A provider then supplies the implementation for specific algorithms in the specified algorithm type. For example, a MessageDigest class provides support for a message digest algorithm. Providers supply implementations for different message digest algorithms, such as MD5 or SHA-1.

Cryptographic Providers As discussed in the preceding section, providers supply implementations for the various engine classes in JCA. Cryptographic Service Providers (CSPs) are packages that implement engine classes for different algorithms. SUN is the default provider of Java SDK and supplies implementations for the DSA, MD5, and SHA-1 algorithms. Other providers can contain implementations for either similar or different algorithms. A program requests for a particular engine instance implementing a particular algorithm, such as a Signature instance with DSA implementation. An installed provider can fetch this implementation or the program can also place a request for a specific provider. Every JDK installation has one or more provider packages provided with it. However, providers can also be added by using the Provider class. Client machines can configure different providers in their runtime marked by a preference order. When a program requests for a specific algorithm but does not specify a provider name, all the installed providers are checked for the required implementation according to the specified preference order. The core classes and interfaces in JCA are Provider, Security, MessageDigest, Signature, KeypairGenerator, Key, and related classes. These classes have already been discussed in Chapter 8, “Security Configuration Files and Security APIs”. The concept of a provider in JCA is implemented via the Provider class. The Provider class constructor sets the values of certain properties that are used by the

303

304

Part II


Java security API. These properties help the Java system look for algorithms and features implemented by the specified provider. The Provider class methods are used to return the name, version, and preference number of the provider. These methods also provide information about the message digest or signature algorithms. Consider the following code statement: MessageDigest md = MessageDigest.getInstance(“SHA-1”);

The preceding code statement can be used by an application that needs an implementation of the SHA-1 message digest algorithm. This code statement creates an instance of the message digest engine class for the SHA-1 message digest algorithm. When this statement is executed, the getInstance() method passes the request for the specified object to the Security class. Because no provider is specified in the given code statement, the Security class searches for the requested implementation among all providers according to their preference order. It continues its search until the provider with the desired implementation is found. The SUN provider is searched first for this implementation because it is the default provider and is listed with preference order 1 in the security properties file. The required implementation is found in the sun.security.provider.SHA-1 class. This implementation is passed to the getInstance() method that creates an object md by using the implementation provided by the sun.security.provider.SHA-1 class. If the SUN provider did not provide the desired implementation, the next provider in the list would be searched. If the Security class traverses the entire list but cannot locate the desired provider implementation, the application throws NoSuchAlgorithmException. As discussed in the preceding discussion, the order in which the providers are listed in the java.security file is very important. It is the same order that the Security class follows while looking for a specific implementation. By default, there are provider packages installed in Java 2 runtime. You can add more providers or remove them statically by editing the java.security file accordingly. This can also be performed dynamically by using the addProvider(), insertProvider(), and removeProvider() methods of the Security class. These methods are already discussed in Chapter 8, “Security Configuration Files and Security APIs”. You can also place a query regarding the providers installed and the implementations they provide. The Security class provides two methods— getProvider() and getProviders(). The getProvider() method definition is given here: public Provider getProvider(String providerName)

This method returns the provider identified by providerName. If the specified provider is not found, a null value is returned. The getProviders() method definition is given here: public Provider[] getProviders()


Chapter 12

This method returns all installed providers in a Provider array. The order of the providers in the array is same as their preference order. The previously discussed provider architecture provides algorithm and implementation independence for Java applications.

Java Cryptography Extension (JCE) JCE is an extension in Java to meet the encryption needs. It is a set of packages providing implementation of various cryptographic algorithms. Although encryption is an important part that helps in implementing security, JCE is provided as an extension in Java because of the U.S. export restrictions on encryption technology. If Sun included JCE as a core part of the Java platform, it would affect the exportability of Java also. This would, in turn, affect the popularity of the Java platform. JCE follows the same structure pattern as JCA. It is composed of engine classes that relate to algorithms in a general way. These engine classes provide symmetric key encryption, and generate and manipulate secret keys. JCE extends the JCA APIs and includes APIs that support encryption, keys, and MACs. JCE also implements a platformindependent API. You have already read in the preceding section that JCA separates cryptographic concepts from their algorithmic implementations by using the provider architecture. JCE follows the same steps and implements algorithm and implementation independence by using the provider architecture. JCE uses the concept of symmetric key encryption. The SunJCE provider consists of the javax.crypto package that forms the core of JCE. This package has two sub-packages — javax.crypto.spec and javax.crypto.interfaces. The javax.crypto package provides 14 classes, one interface, and four exceptions that implement basic cryptographic functions. The classes are listed here: ◆ Cipher ◆ CipherInputStream ◆ CipherOutputStream ◆ CipherSpi ◆ KeyAgreement ◆ KeyAgreementSpi ◆ KeyGenerator ◆ KeyGeneratorSpi ◆ Mac ◆ MacSpi

305

306

Part II


◆ NullCipher ◆ SealedObject ◆ SecretKeyFactory ◆ SecretKeyFactorySpi

The four exceptions are: ◆ BadPaddingExcpetion ◆ IllegalBlockSizeException ◆ NoSuchPaddingException ◆ ShortBufferException

The preceding exceptions extend from the java.security.GeneralSecurityException class. They define exceptions with respect to the size and padding of data processed by cryptographic algorithms. The javax.crypto package provides a single interface namely, SecretKey, which extends from java.security.Key. This interface provides support for symmetric and secret-key cryptography. The javax.crypto.spec package provides the following 12 classes that support key and algorithm parameter specifications: ◆ DESedeKeySpec ◆ DESKeySpec ◆ DHGenParameterSpec ◆ DHParameterSpec ◆ DHPrivateKeySpec ◆ DHPublicKeySpec ◆ IvParameterSpec ◆ PBEKeySpec ◆ PBEParameterSpec ◆ RC2ParameterSpec ◆ RC5ParameterSpec ◆ SecretKeySpec

These key specifications allow keys to be defined in a provider-independent manner. The algorithm parameter specifications define the parameters used with various cryptographic algorithms.


Chapter 12

The javax.crypto.interfaces package provides three interfaces that support Diffie-Hellman keys. These are listed here: ◆ DHKey ◆ DHPrivateKey ◆ DHPublicKey

The DHKey interface provides access to a Diffie-Hellman key, whereas the DHPrivateKey and DHPublicKey interfaces provide access to the private and public key components.

NOTE The Diffie-Hellman key is an agreement protocol. It is also called exponential key agreement and was developed by Diffie and Hellman in 1976. This protocol allows two users to exchange a secret key over an insecure medium without sharing any secret keys.

I’ll discuss the crucial classes in the previously discussed packages in the subsequent sections.

The javax.crypto.Cipher Class This is an important class of the JCE framework. It provides implementation of a cryptographic cipher that is an algorithm used to convert plain text to cipher text. This class is mainly used for encryption and decryption. Similar to other engine classes discussed in the JCA framework, this class is also instantiated by using the getInstance() method. This method takes a String object as a parameter that represents a string specifying the operations to be performed on the input to deliver the output. This string is called a transformation. It includes the cryptographic algorithm name, feedback mode, and padding scheme. Therefore, the transformation string is either algorithm/mode/padding or algorithm. When the mode or padding scheme is not specified, default values specified by the provider definition are used. The mode can be either encryption or decryption mode. These modes are represented by symbolic names namely, ENCRYPT_MODE and DECRYPT_MODE, which are integer constants in the Cipher class. Cryptographic algorithms operate on predefined data blocks. The plain text packets to be converted to cipher text by using these algorithms are of a specific length, which is not a multiple of the block size. Therefore, these packets are to be padded before encrypting them by using a suitable padding scheme.

307

308

Part II


The input buffer size is 64 bits, therefore, when less than eight bytes of plain text are to be encrypted, additional bytes are added to complete the 64-bit size. This process is known as padding. Consider the following code statement: Cipher c = Cipher.getInstance(“DES/CBC/PKCS5Padding”);

In the preceding statement, I can use the DES algorithm that uses the following modes of operation: ◆ Cipher Block Chaining (CBC) mode performs encryption by using 8-byte

blocks. The cipher text output when encrypting block “n” is XORed with the plain text block of “n+1”. ◆ Cipher Feedback Mode (CFB) performs encryption on a number of bits less

than 64 bits. The cipher text output of previous bits is XORed with the plain text of new bits. ◆ Electronic Codebook (ECB) mode performs encryption in 80-byte blocks

with the following cipher text that is independent of the previous plain text or cipher text. ◆ Output Feedback (OFB) mode uses DES to create a pseudo-random bit

stream, which is combined with plain text using a XOR relation. The output is a cipher text stream. Public Key Cryptography Standard # 5 (PKCS#5) padding is a standard developed by RSA Data Security Inc. for performing padding. The created Cipher object is initialized by invoking the init() method. The Cipher object loses all previously acquired states. Data can be encrypted or decrypted in one step by invoking the doFinal() method. It can also be performed in multiple steps by invoking the update() method. Performing the data encryption and decryption in multiple parts is useful when the data is too long to be stored in the memory in one shot or if the length of the data is not known.

The CipherInputStream and CipherOutputStream Classes These classes combine secure input and output streams with a Cipher object. The CipherInputStream class is a filtered input stream that encrypts and decrypts data passing through it. It consists of an InputStream and a Cipher class. The read() methods of this class, therefore, return data that is read from the input stream and processed by the Cipher object. However, the Cipher object should be initialized before being used by the CipherInputStream class. If the Cipher object was


Chapter 12

initialized for encryption, the CipherInputStream class encrypts the data read from the input stream and returns it to the application. The CipherOutputStream class is a filtered output stream that encrypts and decrypts the data passing through it. It consists of an OutputStream and a Cipher class. The write() methods of this class process data with the Cipher object and then write it to the underlying output stream. However, the Cipher object should be initialized before being used by the CipherOutputStream class. If the Cipher object was initialized for encryption, the CipherOutputStream class encrypts the data before writing it to the output stream.

Using the Cipher Class In this section, I’ll write a simple Java code that enumerates the usage of the Cipher class. Consider the following code: import java.io.*; import java.security.*; import javax.crypto.*; class UseCipher{ public static void main(String args[]) { try{ //Create keys and key generators KeyGenerator KG = KeyGenerator.getInstance(“DES”); Key sigKey = KG.generateKey(); //Create Cipher objects for encryption and decryption Cipher c1 = Cipher.getInstance(“DES”); Cipher c2 = Cipher.getInstance(“DES”); //Initialize Cipher objects c1.init(Cipher.ENCRYPT_MODE, sigKey); c2.init(Cipher.DECRYPT_MODE, sigKey); //Create the encrypting cipher stream FileInputStream fis = new FileInputStream(“C:/encryptdata.txt”); CipherInputStream cis1 = new CipherInputStream(fis, c1); //Create the decrypting cipher stream CipherInputStream cis2 = new CipherInputStream(cis1, c2); //Write the decrypted data to an output file FileOutputStream fos = new FileOutputStream(“C:/decryptdata.txt”);

309

310

Part II


byte[] bytearray = new byte[1024]; int i = cis2.read(bytearray); while(i != -1) { fos.write(bytearray, 0, i); i = cis2.read(bytearray); } fos.close(); cis1.close(); cis2.close(); } catch(Exception e) { System.out.println(“Exception: ” + e); } } }

For the preceding program to run, SunJCEProvider should be installed on the system. This program uses two cipher objects to encrypt and decrypt the data. One cipher object is initialized to the DES algorithm in the ENCRYPT_MODE, whereas the second one is initialized to the DES algorithm in the DECRYPT_MODE. The decrypted output is stored in an output file. After running the preceding program, the text in both the files is similar.

The javax.crypto.KeyAgreement Class Transmission of data between two parties over an unsecured connection occurs through a secure communication channel between the two parties. The parties perform this transmission by using the same secret key to transmit it securely over the channel. They can transmit the key securely by using asymmetric encryption. However, you can also use a key agreement for the same. A key agreement is a protocol allowing the parties on both ends of the channel to calculate the secret key value without transmitting the secret key over an unsecured connection. Therefore, the different parties can use symmetric encryption without exchanging the secret key. An example of such a protocol is the Diffie-Hellman algorithm. This protocol is implemented by the javax.crypto.KeyAgreement class. The keys used in this protocol are created by KeyGenerator objects. You’ll read about the KeyGenerator class in a subsequent section. You can create instances of the KeyGenerator class by using the getInstance() method. A String representing the key agreement algorithm is passed as a parameter


Chapter 12

to this method. You can also specify the name of the provider as a second parameter to the method. If you specify only the algorithm name, the system searches for the specified algorithm implementation in the runtime environment and it selects the most preferred implementation. However, if the provider is also specified, the system looks for the algorithm implementation in the specified provider package. An exception is thrown if the suitable implementation is not found. The KeyAgreement instance can be initialized by using a private key, a source of randomness, and a set of algorithm parameters. The key agreement protocol performs its operations in a series of steps. The doPhase() method executes the subsequent phase in the key agreement. A key and a boolean variable are passed as parameters to the method. The Key parameter represents the key to be processed by the current phase. This could be a public key of either of the communicating parties or an intermediate key generated by the earlier phase. The boolean parameter determines whether the current phase is the last phase in the key agreement process or whether there are subsequent phases as well. A true value indicates that the current phase is the last phase of the key agreement. A false value indicates that this is not the last phase of the key agreement. The doPhase() method returns an intermediate key that is passed to the subsequent phases. After all key agreement phases are complete, the shared secret key is computed by invoking the generateSecret() method.

The javax.crypto.KeyGenerator Class The KeyPairGenerator class is a part of the Java 2 APIs. It is used to generate a public/private key pair. On the other hand, the KeyGenerator engine class in JCE is used to generate keys for symmetric key algorithms. Instances of this engine class are also created by invoking the getInstance() method. The parameters passed to this method are the name of the symmetric key algorithm and a provider name. The provider parameter is optional. If both the parameters are specified, the system looks for the specified algorithm implementation in the specified provider package. If only the algorithm name is specified, the system looks for the implementation in the most preferred installed provider. A KeyGenerator object for a specified algorithm creates a symmetric key that can be used with the specified algorithm.

The javax.crypto.SealedObject Class This class encrypts and seals any serializable object by using a Cipher object. A SealedObject instance creates an object that contains the original serialized object and encrypts or seals this object by using a cryptographic algorithm. The sealed object can be decrypted and the original state can be regained by using this class. You can decrypt it by using the same Cipher object that was used in encryption. You’ll also

311

312

Part II


need the same key and algorithm parameters used during encryption. An alternative way is to use the decryption key.

The Secret Key Classes and Interfaces JCE supports interfaces and classes that support secret keys. These are the javax.crypto.SecretKey interface, javax.crypto.SecretKeyFactory class, and the javax.crypto.spec.SecretKeySpec class. I’ll discuss these classes and interfaces in this section. The javax.crypto.SecretKey interface does not contain any methods. This interface groups secret keys. It extends the Key interface. Providers implementing this interface support the equals() and hashCode() methods of the Object class. These methods compare secret keys based on their underlying key material and not reference. The javax.crypto.SecretKeyFactory class identifies a factory for secret keys. These factories are bi-directional. This indicates that they can retrieve the underlying key material of a Key object in a desired format or create a Key object by using the given key material. Key factories are used to convert keys to key specifications that reveal the underlying key material. The javax.crypto.spec.SecretKeySpec class identifies a secret key that is providerindependent. This class creates a secret key without using the key factory that is provider-based. Instead, it uses a byte array. This class is useful for DES and TripleDES keys that can be represented by a byte array and don’t have any key parameters associated with them.

Provider and Algorithm Independence in JCE The most important feature of JCA and JCE is the usage of cryptographic provider packages. These providers enable implementation-independence. The cryptographic package provider support defines a framework that supports algorithm extension as well. This indicates that the API can be extended by using additional algorithms and provide fast and secure implementation of algorithms. As was already discussed in the JCA section, applications can query the Java runtime for the available providers. Providers can be added both statically and dynamically. SunJCE is the default provider with JCE 1.2. It provides all popular algorithms to implement the classes supported by the JCE API. These implementations are listed here: ◆ An MD5 implementation with DES-CBC Password-Based Encryption

(PBE) algorithm as specified in PKCS#5 ◆ Padding scheme implementation as specified in PKCS#5


Chapter 12

◆ HMAC-MD5 and HMAC-SHA1 keyed-hashing algorithm

implementation ◆ Key generators for generating keys for DES, Triple-DES, HMAC-MD5,

and HMAC-SHA1 algorithms ◆ Implementation of Data Encryption Standard (DES), Triple-DES

algorithms in the ECB, CBC, CFB, and OFB modes ◆ Diffie-Hellman (DH) key agreement algorithm implementation ◆ A DH key pair generator implementation ◆ A DH algorithm parameter generator ◆ A DH key factory

Creating Your Own Provider SUN and SunJCE are default providers in Java 2 SDK. You can use the implementations provided by these provider packages only if JCE 1.2 is installed on your system. If you specify your own cryptographic algorithms, you need to write associated provider packages as well. The provider implementations can vary. They can be either platform independent or dependent or they may be software- or hardware-based. In this section, I’ll discuss the steps for implementing your own providers. First, depending on the cryptographic services that you are providing, you need to provide the code for algorithm implementations. The various services that you can provide are listed here: ◆ Secret key generation services ◆ PRNG algorithms ◆ Key stores ◆ MACs ◆ Message digests ◆ Secret key factories ◆ Key pair generation

These are just few of them; you can implement many more. For each or the service listed here, you need to define a subclass of the associated SPI class. This subclass should contain: ◆ A public constructor without any parameters ◆ An abstract method with names prefixed with the engine keyword

313

314

Part II


Then, you need to supply a name for the provider implementation so that applications can reference the provider with the name supplied. Next, you need to write a master class for your provider implementation. This is generally a subclass of the Provider class. The subclass should have a final implementation with a constructor that calls the super() method with the specified provider name. The constructor also needs a parameter specifying the version number and the supported algorithms. Consider the following code statement: super(“MyProvider”, 1.1, “Provider supports secret key generation and DES encryption.”);

The services implemented by the provider are marked by a property with the name indicating the type of service, followed by a period and the name of the algorithm, keystore type, or certificate type for which the service is identified. Examples of service types are MessageDigest, Signature, SecureRandom, CertificateFactory, KeyStore, and KeyFactory. The property value should be equal to the fully qualified class name that implements these services. Examples of such classes are Cipher, KeyAgreement, Mac, and SecretFactory. Consider the following code statement: put(“MessageDigest.MD5”, “com.mycompany.provider.MD5MessageDigest”)

This statement defines the MD5 message digest algorithm in a class named MD5MessageDigest. This class is present in the com.mycompany.provider package. For Cipher services, the algorithm name is replaced by the transformation string that contains the algorithm name, operation mode, and padding scheme. These parameters are set by invoking the getInstance() method of the Cipher class, which, in turn, invokes the engineSetMode() and engineSetPadding() methods of the provider CipherSpi subclass. The Cipher property in the provider master class can be identified by any of the following formats: ◆ Cipher.algorithmName/mode/padding. Implements the algorithm with algorithmName with the specified mode and padding. ◆ Cipher.algorithmName//padding. Implements the algorithm with algorithmName with the specified padding but pluggable mode. ◆ Cipher.algorithmName. Implements the algorithm with algorithmName with the pluggable mode and padding. ◆ Cipher.algorithmName/mode. Implements the algorithm with algorithmName with the specified mode but pluggable padding.

Following is the code for a sample master class: package com.mycompany.provider;


Chapter 12

import java.security.AccessController; import java.security.Provider; public final class MyProvider extends Provider { private static String providerInfo = “This is the second version of MyProvider that implements the DES and MD5 algorithms”; public MyProvider() { super(“MyProvider, 1.1, providerInfo”); AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { put(“MessageDigest.MD5”, “com.mycompany.provider.MD5MessageDigest”); put(“Cipher.DES”, “com.mycompany.provider.DESCipher”); put(“KeyGenerator.DES”, “com.mycompany.provider.DESKeyGenerator”); return null; } }); } }

Next, compile this master class. After the class files are created, you can create a JAR file to store them. Finally, you can test whether the provider implementation is ready to use. You can write a program that fetches the provider and tests whether the current algorithms supplied by the provider are available. Consider the following code: import java.security.*; import java.util.*; class TestProvider{ public static void main(String[] args) { System.out.println(“Fetching providers…………”); Provider[] providers = Security.getProviders(); for(int i = 0; i< providers.length; i++) { System.out.println(“Name:” + providers[i].getName()); System.out.println(“Version:” + providers[i].getVersion());

315

316

Part II


System.out.println(“Info :” + providers[i].getInfo()); } } }

Summary In this chapter, I discussed the cryptographic services provided in Java 2. I started the discussion by explaining the need for cryptography. I explained symmetric and asymmetric algorithms. Next, I discussed Java Cryptography Architecture ( JCA). I also talked about the cryptographic algorithms, engines, and providers in JCA. Next, I discussed Java Cryptography Extension ( JCE) and the core package of JCE, javax.crypto. I explained the usage of important classes in this package namely, Cipher, KeyAgreement, KeyGenerator, and SealedObject. Finally, I discussed the process of implementing your own provider.

Check Your Understanding Multiple Choice Questions 1. Bob and Joe are transmitting confidential data over an unsecured network connection. They are using cryptographic services to impart confidentiality and integrity of data. They are using the same secret key for this secure data transmission. Which of the following algorithms are they using for secure data transmission? a. Asymmetric key algorithm b. DES algorithm c. Symmetric key algorithm d. RSA algorithm 2. A data packet signed by Caryl is transmitted to Mark. How can Mark determine that the public key used by Caryl actually belongs to her? a. Message digests b. MACs c. Public key certificates d. Secret key


Chapter 12

3. Which of the following features is indicative of the JCA framework? a. Implementation independence b. Algorithm extensibility c. Algorithm independence d. Implementation interoperability 4. SUN is the default provider of the Java SDK. Which of the following algorithmic implementations does it provide? a. DSA b. MD5 c. SHA-1 d. DES 5. Which of the following methods allows you to query a provider implementation? a. addProvider() b. removeProvider() c. getProvider() d. getProviders() 6. Which is the core package of the SunJCE provider? a. java.security b. javax.crypto c. javax.crypto.spec d. javax.crypto.interfaces 7. For a transformation string in a Cipher.getinstance() method, which of the following parameters are optional? a. Algorithm b. Mode c. Padding d. Entire transformation string

Short Questions 1. Differentiate between symmetric and asymmetric key algorithms. 2. Explain how the provider architecture in JCA provides implementation independence.

317

318

Part II


Answers Multiple Choice Answers 1. b and c. In symmetric key encryption, both the encryption and decryption occur by using the same cryptographic or secret key. Therefore, symmetric keys help in maintaining confidentiality of data if the shared secret key is not passed to another identity. 2. c. Digital certificates certify the value of the signer’s public key. They are messages that are signed by a certification authority (CA). 3. All of the options are correct. JCA is both implementation and algorithm independent. Therefore, users can access cryptographic functions without the overhead of knowing the implementation or algorithm that supports the particular function. Multiple implementations and algorithms are supported by a single encryption session. Therefore, there should be interoperability between the different implementations and algorithms so that a signature generated by a specific provider can be verified by another provider implementation. The algorithms are extensible so that a new algorithm supported by an engine class can be added easily to the architecture. 4. a, b, and c. SUN is the default provider of the Java SDK and supplies implementations for the DSA, MD5, and SHA-1 algorithms. 5. c and d. You can place a query regarding the providers installed and the implementations they provide. The Security class provides two methods— getProvider() and getProviders(). 6. b. The SunJCE provider consists of the javax.crypto package that forms the core of JCE. 7. b and c. The transformation string is either algorithm/mode/padding or algorithm. When the mode or padding scheme is not specified, default values specified by the provider definition are used.

Short Answers 1. There are two types of keys that perform the encryption process—symmetric and asymmetric keys. In symmetric key encryption, both the encryption and decryption occur by using the same cryptographic or secret key. Therefore, symmetric keys help in maintaining confidentiality of data if the shared secret key is not passed to another identity. On the other hand, asymmetric keys have different values at either end. One end can use a public key that can be shared with everyone whereas another end uses a private key that cannot be shared. If the public key is used while decrypting data, no confi-


Chapter 12

dentiality is maintained because anyone can decipher the data. However, because a private key is used for encrypting, the data has the identity of the person who signed it. On the other hand, if the private key is used to decipher data, confidentiality is being maintained because only the person possessing the private key can decipher the data. However, there is no identity of the data at the encrypting end because anyone possessing the public key can sign the data. 2. Providers supply implementations for the various engine classes in JCA. Cryptographic Service Providers (CSPs) are packages that implement the engine classes for different algorithms. SUN is the default provider of the Java SDK and supplies implementations for the DSA, MD5, and SHA-1 algorithms. Other providers can contain implementations for either similar algorithms or different ones. A program requests for a particular engine instance implementing a particular algorithm, such as a Signature instance with DSA implementation. An installed provider can fetch this implementation or the program can also place a request for a specific provider. Every JDK installation has one or more provider packages provided with it. However, providers can also be added by using the Provider class. Client machines can configure different providers in their runtime marked by a preference order. When a program requests for a specific algorithm but does not specify a provider name, all the installed providers are checked for the required implementation according the specified preference order. The concept of a provider in JCA is implemented via the Provider class. The Provider class constructor sets the values of properties that are used by the Java security API to look for algorithms and features implemented by the specified provider. The Provider class methods are used to return the name, version, and preference number of the provider. There are methods that also provide information about the message digest or signature algorithms. Consider the following code statement: MessageDigest md = MessageDigest.getInstance(“SHA-1”);

The preceding code statement can be used by an application that needs an implementation of the SHA-1 message digest algorithm. This code statement creates an instance of the message digest engine class for the SHA-1 message digest algorithm. When this statement is executed, the getInstance() method places the request for the specified object to the Security class. Because no provider is specified in the given code statement, the Security class searches for the requested implementation among all the providers according to their preference order. It continues its search until the provider with the desired implementation is found. Because the SUN

319

320

Part II


provider is the default provider and is listed with preference order 1 in the security properties file, it is searched first for this implementation. The required implementation is found in the sun.security.provider.SHA-1 class. This implementation is passed to the getInstance() method, which creates an object md by using the implementation provided by the sun.security.provider.SHA-1 class. If the desired implementation was not provided by the SUN provider, the next provider in the list would be searched. If the Security class traverses the entire list but cannot locate the desired provider implementation, the application throws NoSuchAlgorithmException. As seen in the preceding discussion, it is clear that the order in which the providers are listed in the java.security file is very important. It is this same order that the Security class follows while looking for a specific implementation. Therefore, the previously discussed provider architecture provides algorithm and implementation independence for Java applications.

Chapter 13 Introduction to Java Authentication and Authorization Service (JAAS)

J

ava Authentication and Authorization Service ( JAAS) is a core extension of the Java 2 SDK. As you learned in the preceding chapters, it is clear that Java 2 provides access control based on the origin of the code and who signed it. However, there is no support through which you can authenticate users who run the code. JAAS implements this support in Java 2. JAAS authenticates subjects based on the built-in authentication mechanisms. JAAS also authorizes subjects depending on their authentication status. This chapter provides an overview of JAAS and the APIs that support JAAS. It also discusses authentication and authorization models of JAAS.

An Overview of JAAS JAAS is mainly formed of two components, authentication and authorization. The authentication component determines the identity of the user irrespective of whether the code is an application, applet, or servlet. On the other hand, the authorization component implements the Java 2 security framework and restricts the code that performs sensitive tasks. The authorization component does this by checking the code source and the user who was authenticated. JAAS authentication provides a pluggable interface. Due to this there is no built-in authentication technology in Java applications. This enables incorporation of new and updated authentication technologies into any Java application without modifying it. In a Java application, the authentication process is instantiated through a LoginContext object. The LoginContext object refers to the Configuration object that determines the current authentication technology. The application then invokes LoginModule that performs authentication. Generally, authentication is provided by prompting for the username and password or by verifying a voice or fingerprint sample. After user authentication, the authorization component protects access to crucial resources. This authorization is performed in addition to the default Java 2 security access control checks. Therefore, by using JAAS, access control decisions depend on the code source and the user running the code. JAAS also provides a security policy, which is an extension of the Java 2 security policy. The JAAS security policy provides subject-based information. However, the permissions explained in a security policy file in Java 2 are also understood by JAAS. Now, let’s discuss the core APIs that support JAAS.

JAVA AUTHENTICATION AND AUTHORIZATION SERVICE

Chapter 13

Core JAAS APIs JAAS architecture consists of the following packages: ◆ The javax.security.auth package consists of classes and interfaces for

authentication and authorization. ◆ The javax.security.auth.login package consists of classes that help

during logging to a security domain. ◆ The javax.security.auth.spi package consists of an interface that imple-

ments a login module supplied by JAAS providers. ◆ The javax.security.auth.callback package consists of classes and inter-

faces that pass authentication information to an application by invoking a link between the application and security service. The preceding packages consist of the core classes in JAAS. They are divided into three main categories as listed here: ◆ Common classes that are shared by the authentication and authorization

modules ◆ Authentication classes that are used to authenticate subjects ◆ Authorization classes that authorize an authenticated subject for resource access

The common classes contain the Subject, Principal, and Credential classes. The authentication classes contain the LoginContext, LoginModule, CallbackHandler, and Callback classes. The authorization classes contain the Policy, AuthPermission, PrivateCredentialPermission classes. I’ll discuss these classes in detail in the subsequent sections.

The Subject Class JAAS authorizes resource access by authenticating the source of the request, which is identified by the Subject class. The subject requesting a resource can be a person or service. A Principal object distinguishes a particular subject from the other subjects. Therefore, a subject can have multiple identities or principals associated with it. For example, for a Subject person the name, social security number, and address can be the associated Principals. A Subject object also contains security-related attributes that are represented by the Credential class. Highly secret attributes requiring extra protection, such as private keys, are stored in the private credential Set. Shareable attributes on the other hand, such as public keys, are stored in the public credential Set. These sets are based on the java.util.Set collections. These different sets are managed by different permissions.

323

324

Part II


Creating Subjects You can create subjects by using the following constructor: public Subject(boolean readOnly, Set principals, Set pubCredentials, Set privCredentials);

This constructor creates a Subject instance with the specified set of principals and credentials. The boolean parameter makes the Subject instance read-only. If the Subject instance is not read-only at the time of creation, it can be set later by using the setReadOnly() method. However, to invoke this method, you need AuthPermission. In read-only state, you cannot modify the Subject instance.

Handling Subject Attributes After creating a Subject instance, you can retrieve its attributes—namely, the Principal and Credential objects. To retrieve the principals associated with a given Subject object, you can use any of the following methods: public Set getPrincipals(); public Set getPrincipals(Class c);

The first method returns the entire Principal set of the particular Subject instance. The second method returns only the principals associated with the specified Class c. If there are no principals associated with the specified class, a null set is returned. To retrieve the public Credentials set, you can use one of the following methods: public Set getPublicCredentials(); public Set getPublicCredentials(Class c);

They operate in the same manner as the Principal methods. Similarly, to retrieve the private Credentials set, you can use one of the following methods: public Set getPrivateCredentials(); public Set getPrivateCredentials(Class c);

To modify the public or private credential Set or to modify the principal Set, you can use the methods of the java.util.Set class. Consider the following code: Subject subject; Principal principal; Object credential; // Use the following methods to add the specified principal // and credential object to the Subject instance. Subject.getPrincipals().add(principal); Subject.getPublicCredentials().add(credential);


Chapter 13

However, for the preceding code to be successful in its operation, you need to specify the respective AuthPermission. For example, AuthPermission (“modifyPrivateCredentials”) needs to be specified for modifying the private credentials set. Consider the following method: public static Subject getSubject(final AccessControlContext acc);

The preceding method returns the Subject object associated with the specified AccessControlContext. For an object to perform a similar action as a particular Subject, you can invoke the following methods: public static Object doAs(final Subject subject, final java.security.PrivilegedAction action); public static Object doAs(final Subject subject, final PrivilegedExceptionAction action) throws PrivilegedActionException;

The preceding methods perform the specified action on the subject associated with the current thread’s AccessControlContext. The doAsPrivileged() methods perform a similar function as the previously discussed doAs() methods. The only difference being that rather than associating the Subject with the current thread’s AccessControlContext, the doAsPrivileged() methods use the AccessControlContext itself. The Credential classes implement two interfaces — namely, Refreshable and Destroyable. The credential with Refreshable interface has the ability to refresh itself. This interface contains two methods, isCurrent() and refresh(). The is Current() method determines whether the credential is current or valid. The refresh() method updates or extends the validity period of the specified credential. The Destroyable interface has the ability to destroy the contents of a credential. This interface also supports two methods, isDestroyed() and destroy(). The isDestroyed() method determines whether the credential has been destroyed. On the other hand, the destroy() method destroys the contents of a credential.

JAAS Authentication In JAAS, to authenticate a Subject instance, an application instantiates a LoginContext object. This is done to present principal credential information to JAAS. The LoginContext instance loads the login modules configured for a specified application. Then, the application invokes the login() method of the LoginContext class. The login() method, in turn, invokes all the loaded login modules, which authenticate the specified Subject. If these modules successfully authenticate a Subject, they associate principals and credentials with the authenticated Subject. The LoginContext class returns theauthentication status to the application. If the authentication is successful, the application retrieves the Subject instance from the LoginContext instance.

325

326

Part II


The LoginContext Class The LoginContext class authenticates Subjects by using its built-in methods. It follows the Pluggable Authentication Module (PAM) framework, which creates an application independent of the underlying authentication technology. The LoginContext class refers to various LoginModules instances for a particular application. Because there are multiple LoginModules for a specified application, you need not change the application for incorporating an authentication framework. You can create LoginContext objects by using one of the following four constructors: public LoginContext(String name) throws LoginException; public LoginContext(String name, Subject subject) throws LoginException; public LoginContext(String name, CallbackHandler cbh) throws LoginException; public LoginContext(String name, Subject subject, CallbackHandler cbh) throws LoginException;

The preceding constructors share a common String parameter, name. This parameter creates a LoginContext object for a named authentication configuration. This configuration name identifies the methodologies used for logging into an application and the parameters associated with them. If the Subject parameter is missing, a new Subject instance is created. Authentication is performed by invoking the login() method. public void login() throws LoginException;

If the login is successful, the authenticated Subject can be retrieved by calling the getSubject() method. To log out of Subject, you can invoke the logout() method. Refer to the following code statements for understanding of the entire authentication process: LoginContext context = new LoginContext(“entry”); try{ //Authenticate the subject context.login(); System.out.println(“Authentication successful”); //Retrieve the authenticated subject Subject subject = context.getSubject(); // Perform operations //log out context.logout(); } catch(LoginException e){ System.out.println(“authentication was unsuccessful:”+e); }


Chapter 13

The LoginModule Interface This interface offers developers various authentication technologies, which can be plugged into any application without modifying its structure. Examples of various authentication technologies include username-password authentication or using hardware, such as smart cards. A Configuration object specifies the login module to be used with a particular login application. Using this object, different login modules can be plugged into a given application. The LoginContext object reads the Configuration object and instantiates the associated LoginModule. To initialize a LoginModule instance, the LoginContext object calls the initialize() method of the LoginModule instance. The definition of the initialize() method is given here: void initialize(Subject subject, CallbackHandler cbh, Map sharedState, Map options);

The login() method begins the authentication process. This method can either implement the username-password scheme or use smart cards or biometric devices for authentication. This is the first phase of the JAAS authentication process. The commit() method finalizes the authentication process. It proceeds to second phase if the first phase is complete. In the second phase, the commit() method links the principals and credentials with the specified Subject instance. However, if the first phase is not successful, the commit() method removes the stored usernames and passwords. The authentication process is terminated by the abort() method. Finally, to log out of a particular Subject, the logout() method is invoked. This method removes the associated principals and credentials. The preceding discussion talked about the steps that implement LoginModule. There is an AuthenticationFlag value associated with a LoginModule entry. This AuthenticationFlag can take the following values: ◆ The Optional value indicates that the login module is not required for

authentication of the subject. ◆ The Required value indicates that the login module must be successful for

the success of the entire authentication process. The authentication process continues for the other login modules even if one is unsuccessful. ◆ The Requisite value indicates that the login module must be successful for

the success of the entire authentication process. The authentication process is terminated even if a single login fails. ◆ The Sufficient value indicates that authentication of a single login module

is sufficient for the entire process to be successful.

327

328

Part II


The CallbackHandler Interface There are situations when a login module needs certain authentication information from a user or when the module needs to notify the user of certain events during the authentication process. This is done through callbacks. The Java API provides the CallbackHandler interface for this purpose. Applications implement this interface and pass it to LoginContext, which then passes it to the underlying LoginModule. Login modules use this interface to capture information from the user or to provide the user with certain information during the authentication process. Various login modules are independent of implementation of the CallbackHandler interface because this is monitored by the concerned application. There is only one method provided in this interface, handle(). The definition of the handle() method is given here: void handle(Callback[] callbacks) throws java.io.IOException, UnsupportedCallbackException;

The handle() method takes an array of Callback objects as a parameter that is used to retrieve or display the authentication information. The Callback and CallbackHandler interface are a part of the javax.security.auth.callback package. Different types of callback mechanisms implemented by various classes of the javax.security.auth.callback package are listed here: ◆ The ChoiceCallback class displays a list of choices present during authenti-

cation. It also allows the application to select from the various available authentication options ◆ The ConfirmationCallback class retrieves confirmation information for the authentication process. Various types of confirmations available are YES/NO, YES/NO/CANCEL, or OK/CANCEL. ◆ The LanguageCallback class retrieves geographic and regional information

used during authentication. ◆ The NameCallBack class retrieves name information during authentication. ◆ The PasswordCallback class retrieves password information during the

authentication process. ◆ The TextInputCallback class provides generic text input information to the

authentication process. ◆ The TextOutputCallback class displays output information, such as warn-

ing, error, or information messages. Consider the following code snippet that can be added to a login() method while implementing a login module. if(callbackHandler == null) { throw new LoginException(“You cannot login without a handler instance!!!”);


Chapter 13

} //Create a callback instance for the username and password NameCallback name = new NameCallback(“Username: ”); PasswordCallback password = new PasswordCallback(“Password: ”, false); // Add these objects to a Callback array //Create a Callback array Callback callbacks[] = new Callback[2]; callbacks[0] = name; callbacks[1] = password; //Pass this array to the CallbackHandler’s handle() method try{ callbackHandler.handle(callbacks); } catch(Exception e){ System.out.println(“Login unsuccessful”); } //Retrieve the username and password for future operations String userName = name.getName(); char[] userPassword = password.getPassword(); // Implementation of the handle() method public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {

for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) {

// prompt the user for a username NameCallback nc = (NameCallback)callbacks[i]; System.err.print(nc.getPrompt()); System.err.flush(); nc.setName(userName);

} else if (callbacks[i] instanceof PasswordCallback) {

// prompt the user for sensitive information PasswordCallback pc = (PasswordCallback)callbacks[i]; System.err.print(pc.getPrompt()); System.err.flush(); pc.setPassword(userPassword);

329

330

Part II


} else { throw new UnsupportedCallbackException (callbacks[i], “The Callback is not recognized”); } } }

The implementation of the handle() method is application-specific. Therefore, the implementation in the preceding code can be either through a GUI or non-GUI interface.

JAAS Authorization After the specified subject is authenticated, various JAAS authorization features can be used to restrict access to valued resources. JAAS authorization is an extension of the Java 2 security model authorization process. Fine-grained access control is placed on the specified Subject by invoking the doAs() and doPrivileged() methods of the Subject class. These perform a similar function as the doPrivileged() methods of the AccessController class. The doAs() and doPrivileged() methods of the Subject class take an additional parameter, the Subject object. Consider the following code: class MyAction implements java.security.PrivilegedAction { public Object run() { java.io.File f = new java.io.File(“myFile.txt”);

// You need to perform the associated security check if (f.exists()) { System.out.println(“The file already exists!!!”); } return null; } }

public class TestMyAction { public static void main(String[] args) {

// Steps for authentication of Subject

Subject caryl;


Chapter 13

...

// Caryl will perform MyAction Subject.doAs(Caryl, new MyAction()); } }

When the preceding program executes, MyAction encounters a security check when the f.exists() method is invoked. However, because MyAction is running under the subject Caryl, and because the JAAS policy file grants the associated FilePermission to Caryl, MyAction does not encounter any security problems. If there are any permission discrepancies in the JAAS policy file, SecurityException is thrown. The associated permissions for the doAs() and doPrivileged() method calls are defined in the JAAS policy file as the associated permissions for the AccessContoller.doPrivileged() methods are stored in the security policy file. I’ll discuss the APIs for the authorization process in the subsequent sections.

The Policy Class This is an abstract class and represents the system-wide JAAS policy. The subclasses of the Policy class implement the getPermissions() and refresh() methods. The definitions of these methods are specified here: public abstract PermissionCollection getPermissions(Subject s, CodeSource cs); public abstract void refresh();

The getPermissions() method returns the permissions associated with the specified subject and code source. The refresh() method refreshes the policy file with the changes incorporated since the last time it was loaded. This method requires AuthPermission(“refreshPolicy”). The Policy object can be fetched by invoking the getPolicy() method. You also need an associated AuthPermission for the same. On the other hand, to set a new runtime Policy object, the setPolicy() method is invoked.

The PolicyFile Class This class defines a default implementation for the Policy class. In other words, it extends from the Policy class. This class represents the policy for the Java runtime. This policy is a collection of multiple policy configuration files. Therefore, you need to fetch these multiple policy configurations and store them in a Policy object. Let’s discuss the method for locating these policy files.

331

332

Part II


You can set different auth.policy.url.n properties in the java.security file. These properties represent the location of various JAAS security policy files. The integer n starts at 1 and continues until n. Consider the following code statements: auth.policy.url.1=file:C:/java/jaas/jaas.policy auth.policy.url.2=file:C:/java/MyPolicy/Myjaas.policy auth.policy.url.3=file:C:/java/config/jaas1.policy auth.policy.url.4=file:C:/java/config/jaas2.policy

Each of the preceding statements represents a URL location of a policy file form where it can be read and loaded. You can use the –Djava.security.auth.policy system property at the command line to specify a policy file present in an application-specific location. This policy file is used in addition to the policy files defined by the auth.policy.url.n properties. However, if the java.security.auth.policy is defined by using a double equals (==) sign rather than a single (=) equals sign, only the specified policy file is loaded and all the other files are ignored. The preceding policy files contain grant entries that enclose multiple permission entries. For example, consider the following code: grant signedBy “alias”, codeBase “URL”, principal principalClass “principalName”, principal principalClass “principalName”, ... { permission Type “name “action”, signedBy “alias”; permission Type “name “action”, signedBy “alias”; .... };

As seen in the preceding grant entry syntax, all entries start with the keyword grant. The signedBy and codeBase pairs are optional. The signedBy entry specifies the names of the people who have signed the Java code. The codeBase entry specifies the location from where the code is loaded. The principal entries are not optional and specify the type of Principal objects for the associated permissions along with the principal name. The permission entry starts with the permission keyword. The Type keyword in the preceding syntax represents the permission type, such as FilePermission or SocketPermission. The action keyword specifies actions associated with the permission, such as read or write for FilePermission. There are certain permissions such as RuntimePermission where no actions are specified but only the named values are specified. Consider the sample grant entry defined here: Grant codeBase “file:C:\MyClasses.jar”, Principal java.jaas.Principal “Caryl” {


Chapter 13

permission java.io.FilePermission “myFile.txt”, “read,write”; };

The preceding grant entry permits read and write operations on myFile.txt for an authenticated subject with the principal name, Caryl. The code for this permission is loaded from the MyClasses.jar file in the C: drive. There can be multiple principals associated with one grant entry. However, the current Subject should have all the specified principals in its Principal set to be granted all permissions specified in the grant entry. Consider the sample code given here: grant Principal mycompany.com.principal “admin”, Principal mycompany.com.jaas.principal “Mike” { permission java.io.FilePermission “/AccInfo”, “read, write”; permission java.net.SocketPermission “yahoo.com”, “connect”; };

The preceding entry grants the administrator of mycompany.com and Mike permission to read and write from the AccInfo directory and also allows them to connect to yahoo.com.

The AuthPermission Class This class represents the basic authentication permissions in JAAS. These are only named permissions and do not have an associated actions list. The AuthPermission objects grant access to the Policy, Subject, LoginContext, and Configuration objects. The AuthPermission objects inherits its methods from the Permission class and defines two public constructors that create AuthPermission instances with the specified name. The target names for an AuthPermission instance are listed here: ◆ doAs allows the users to invoke the doAs() methods of the Subject class. ◆ doAsPrivileged allows the users to invoke the doAsPrivileged() methods of the Subject class. ◆ getSubject allows users to fetch Subjects associated with the current thread. ◆ getSubjectFromDomainCombiner allows users to fetch Subjects associated with the SubjectDomainCombiner class. The SubjectDomainCombiner class

updates protection domains with the subject permissions as specified in the JAAS security policy file. ◆ setReadOnly allows users to set a particular Subject as read-only. ◆ modifyPrincipals sets permissions to modify a Set containing the principals of the Subject object. ◆ modifyPublicCredentials allows users to modify the Set of public credentials for a specified Subject.

333

334

Part II


◆ modifyPrivateCredentials allows users to modify the Set of private credentials for a specified Subject. ◆ getPolicy allows users to access the JAAS policy by invoking the Policy.getPolicy() method. ◆ setPolicy allows users to set the JAAS policy by invoking the Policy.setPolicy() method. ◆ refreshPolicy allows users to refresh the JAAS policy by invoking the Policy.refreshPolicy() method. ◆ refreshCredential allows users to refresh the state of a credential object by calling the Refreshable.refresh() method. ◆ destroyCredential allows users to destroy a credential object by calling the Destroyable.destroy() method. ◆ createLoginContext allows applications to instantiate LoginContext. ◆ getLoginConfiguration allows retrieval of login configuration. ◆ setLoginConfiguration allows applications to set login configuration. ◆ refreshLoginConfiguration allows applications to refresh login

configuration.

The PrivateCredentialPermission Class This class is used to restrict access to the private credential objects associated with a specified Subject instance. The target name for this permission specifies a Credential class name and a set of principals. The only permissible action for this permission is read. Consider the sample grant entry given here: grant { permission PrivateCredentialPermission “java.lang.String java.jaas.MyPrincipal \”caryl\””, “read”; };

The preceding grant entry allows the principal name, caryl, to access the private credentials. If a grant entry with PrivateCredentialPermission and the principal self is defined, the entry grants Subject the rights to access its own private credential. Consider the following grant entry that implements the same: grant principal com.mycompany.Principal “Caryl” { permission PrivateCredentialPermission “myCredential self”, “read”; };


Chapter 13

This entry grants the Caryl subject rights to access its own credential, myCredential. Consider the following grant entry: grant principal com.mycompany.Principal “Caryl” { permission PrivateCredentialPermission “* self”, “read”; };

This entry grants Subject Caryl rights to access her private credentials. Now, let’s discuss the various JAAS settings that need to be configured in the java.security file.

JAAS Settings in the java.security File There are four new security properties defined in the java.security file for implementing JAAS. They can be further split into login configuration properties and authorization properties. The login configuration properties include setting of the login configuration provider and the login configuration URL. The default configuration value in the java.security file is specified here: login.configuration.provider=com.sun.security.auth.login.ConfigFile

You can replace the default JAAS login configuration by specifying an alternative provider class implementation, as specified in the following code statement. login.configuration.provider = com.mycompany.Config

If this provider implementation is not found, JAAS configuration implementation returns to the default settings. You cannot set this configuration provider in the command line prompt. The location of the login configurations can be set by specifying their URL locations by the login.config.url.n property. If there are multiple configuration files, they are combined into one configuration. The default configuration location is file:${user.home}/.java.login.config. The authorization properties include setting the authorization provider and the authorization policy URL. The default JAAS authorization provider is specified as given here: auth.policy.provider=com.sun.security.auth.PolicyFile

An alternative provider class implementation can also be provided by setting the auth.policy.provider property. Consider the following code statement for the same: auth.policy.provider=com.mycompany.Policy

335

336

Part II


You can use the auth.policy.url.n property to set the location of the JAAS policy. The n parameter starts from 1. You have already read how to set multiple JAAS policy files in a preceding section. Following is the code listing of the JAAS properties in the java.security file provided in the Java 2 runtime: # # Java Authentication and Authorization Service (JAAS) properties # # Class to instantiate as the system-wide login Configuration # for authentication. login.configuration.provider=com.sun.security.auth.login.ConfigFile # Use the login Configuration from the user’s home directory. login.config.url.1=file:${user.home}/.java.login.config # Class to instantiate as the system-wide Subject-based # access control Policy. auth.policy.provider=com.sun.security.auth.PolicyFile # Use the access control Policy from the user’s home directory. auth.policy.url.1=file:${user.home}/.java.auth.policy

Summary In this chapter, I discussed the Java Authentication and Authorization Service ( JAAS) in detail. I started by presenting an overview of JAAS. Then, I dealt with the core JAAS APIs. I explained the JAAS authentication and authorization process in detail. Finally, I discussed the JAAS settings in the java.security file.

Check Your Understanding Multiple Choice Questions 1. Which of the following tasks is performed by the JAAS framework? a. Authentication

c. Authorization

b. Configuration

d. Signing services


Chapter 13

2. Which of the following statements is true about the JAAS framework? a. JAAS authentication provides a pluggable interface. b. The authorization component determines the identity of the user of the code irrespective of whether the code is an application, applet, or servlet. c. The authentication component implements the Java 2 security framework and restricts the code that performs sensitive tasks. d. The authorization process is instantiated through a LoginContext object. 3. Which of the following packages consists of classes and interfaces that pass authentication information to an application by invoking a link between the application and security service? a. javax.security.auth b. javax.security.auth.callback c. javax.security.auth.spi d. javax.security.auth.login 4. Which of the following statements is true about the LoginContext class? a. The LoginContext class follows the Pluggable Authentication Module (PAM) framework. b. The LoginContext class refers to a single LoginModule instance for a particular application. c. The LoginContext class refers to various LoginModules instances for a particular application. d. The LoginContext class demands that you change the application for incorporating an authentication framework. 5. Which of the following statements represents the need for the CallBackHandler interface? a. When a login module needs certain authentication information from a user. b. When the authentication process is called back due to insufficient resources. c. When the module needs to notify the user of certain events during the authentication process. d. When the authorization for a specified resource fails. 6. What does the following grant entry signify? grant principal com.mycompany.Principal “Mark” { permission PrivateCredentialPermission “myCredential self”, “read”; };

337

338

Part II


a. This entry grants Subject Mark rights to access his own credential, myCredential. b. This entry grants Subject Mark rights to access his private credentials. c. The preceding grant entry allows the principal name, Mark, to access the private credentials. d. This entry grants the subjects other than Mark rights to access myCredential.

Short Questions 1. Explain the process of JAAS authentication. 2. Explain the JAAS settings in the java.security file.

Answers Multiple Choice Answers 1. a and c. JAAS authenticates subjects based on the built-in authentication mechanisms. JAAS also authorizes subjects depending on their authentication status. 2. a. JAAS authentication provides a pluggable interface. Due to this fact, there is no built-in authentication technology in Java applications. This enables incorporation of new and updated authentication technologies into any Java application without modifying it. 3. b. The javax.security.auth.callback package consists of classes and interfaces that pass authentication information to an application by invoking a link between the application and security service. 4. a and c. The LoginContext class follows the Pluggable Authentication Module (PAM) framework that creates an application independent of the underlying authentication technology. The LoginContext class refers to various LoginModules instances for a particular application. Because there are multiple LoginModules for a specified application, you need not change the application for incorporating an authentication framework. 5. a and c. There are situations in which a login module needs certain authentication information from a user or when the module needs to notify the user of certain events during the authentication process. This is done through callbacks. The Java API provides the CallbackHandler interface for this purpose.


Chapter 13

6. a. This entry grants Subject Mark rights to access his own credential, myCredential.

Short Answers 1. In JAAS, to authenticate a Subject instance, an application instantiates a LoginContext object. This is done to present principal credential information to JAAS. The LoginContext instance loads the login modules configured for a specified application. Then, the application invokes the login() method of the LoginContext class. The login() method, in turn, invokes all the loaded login modules, which authenticate the specified Subject. If these modules successfully authenticate a Subject, they associate principals and credentials with the authenticated Subject. The LoginContext class returns the authentication status to the application. If the authentication is successful, the application retrieves the Subject instance from the LoginContext instance. 2. There are four new security properties defined in the java.security file for implementing JAAS. They can be further split into login configuration properties and authorization properties. The login configuration properties include setting the login configuration provider and the login configuration URL. The default configuration value in the java.security file is specified here: login.configuration.provider=com.sun.security.auth.login.ConfigFile

You can replace the default JAAS login configuration by specifying an alternative provider class implementation, as specified in the following code statement. login.configuration.provider = com.mycompany.Config

If this provider implementation is not found, JAAS configuration implementation returns to the default settings. You cannot set this configuration provider in the command-line prompt. The location of the login configurations can be set by specifying their URL locations using the login.config.url.n property. If there are multiple configuration files, they are combined into one configuration. The default configuration location is file:${user.home}/.java.login.config. The authorization properties include setting the authorization provider and the authorization policy URL.

339

340

Part II


The default JAAS authorization provider is specified as given here: auth.policy.provider=com.sun.security.auth.PolicyFile

An alternative provider class implementation can also be provided by setting the auth.policy.provider property. Consider the following code statement for the same: auth.policy.provider=com.mycompany.Policy

You can use the auth.policy.url.n property to set the location of the JAAS policy. The n parameter starts from 1. You have already learned how to set multiple JAAS policy files. Following is the code listing of the JAAS properties in the java.security file provided in the Java 2 runtime. # # Java Authentication and Authorization Service (JAAS) properties #

# Class to instantiate as the system-wide login Configuration # for authentication.

login.configuration.provider=com.sun.security.auth.login.ConfigFile

# Use the login Configuration from the user’s home directory. login.config.url.1=file:${user.home}/.java.login.config

# Class to instantiate as the system-wide Subject-based # access control Policy. auth.policy.provider=com.sun.security.auth.PolicyFile

# Use the access control Policy from the user’s home directory. auth.policy.url.1=file:${user.home}/.java.auth.policy

Chapter 14 Java and Firewalls

F

irewalls force access-control restrictions between a corporate network and the Internet. Therefore, the applet network connections are affected by the presence of a firewall in a corporate network. In this chapter, I’ll discuss firewalls and the security breaches in the Java applications and firewall systems used in a network. I’ll also discuss the effects of firewalls on Java programs and how to manage with these effects.

An Introduction to Firewalls A firewall is a layer of software or hardware (or both) present between two or more networks. This layer forces certain access-control restrictions on both the networks that it connects. The firewall controls the data communications to and from the corporate network. Generally, the firewall is located between the corporate and external network. Therefore, firewalls protect the secure corporate system from the untrusted external network that can be the Internet or another corporate network. Firewalls can be implemented by either a single hardware system or a combination of routers and servers, both of which control data transmission over the network. There are two types of firewalls—namely packet-filtering firewalls and applicationlevel firewalls. The packet-filtering firewalls determine whether the data packets are to be transmitted by using the IP addresses and ports of the source or destination hosts. The trusted addresses that can pass through the firewall are defined in the header of the data packet. This is a cheap implementation of a firewall because current day routers have built-in filtering capabilities. For example, a firewall may permit data packets to reach port 80 on a Web server, whereas it may reject the packets to other port numbers.

FIGURE 14-1 A firewall is a boundary present between two or more networks

JAVA AND FIREWALLS

Chapter 14

On the other hand, application-level firewalls do not use built-in filtering mechanisms for transmitting data. Instead, they use the specific code for each requested service. This type of firewall maintains a log of all outgoing and incoming traffic. You can restrict the users of an outgoing service, thereby protecting the corporate network from susceptible attacks. These firewalls can examine the logs generated and send indicators to the Web administrator. Even though firewalls are very important for maintaining security in a corporate network, there are certain limitations associated with them. Built-in firewall systems do not offer a high level of security to systems. However, professional firewalls can cost a substantial amount. The performance of a firewall can affect the data transmission rates in a corporate network. Even firewalls are vulnerable to attacks by external computers. The main purpose of a firewall is to check data that passes through it and accept, reject, or modify the data based on the defined security policy requirements. In Java, there are two main areas requiring firewall support—network access to a server by applets and the loading of applets from a server to a client. Therefore, firewalls can be located at both the server end and client end. However, there are certain firewall functions that do not affect Java security. These include the management, logging, and reporting functions. Let’s discuss how programs interact through firewalls in the subsequent section.

The Interaction of Programs through Firewalls There is generally an assumption that networks are protected by a single firewall. However, data may have to pass through multiple firewalls in a network. For example, in a company network, a firewall is defined between the users and the Internet to protect the entire company network. A firewall is also present between a remote server and its connecting networks to protect it. The restriction of the network traffic passing through a firewall has a different effect on the different types of data passing through it. For example, Java programs are affected by firewalls. In some cases, the Java-enabled Web pages that run on your home Internet connection may not run on your company’s network. Refer to Figure 14-2 to understand the interaction of programs through firewalls. Therefore, the Java programs that are being downloaded from a remote server or those attempting to create network connections may be affected. However, Internet access can be provided despite firewalls by using proxy servers and SOCKS gateways. These allow the employees of a company to access the Internet; however, they do not allow external people from accessing the company’s network. I’ll discuss these in the subsequent sections.

343

344

Part II


FIGURE 14-2 Interaction of a program through a firewall

Proxy Servers Proxy servers receive requests from Web browsers, perform access control checks on these requests, and return the specified results back to the browser. Therefore, instead of sending a request directly to the company’s server, the request passes the firewall and goes to the proxy server of the company, at which point it is transmitted to the secure company network. This is done through the proxy HTTP protocol. For example, a request is sent to the corporate server. Actually, the browser sends this request to the proxy server of the company, which contacts the corporate server with the specified request. You might be wondering the reason behind this indirect approach. However, this approach has many advantages. Requests for certain sites can be restricted via the proxy approach. The proxy server acts as a central control point through which all external Web access is monitored. This can be done by blocking the HTTP data, excluding the data from the proxy server itself. All the Web pages visited can be logged along with the address of the requesting computer. While using a proxy server, the IP addresses and the names of internal systems are not displayed on the Internet. You can just see the address of the proxy server. Therefore, an external person does not have access to the internal system names or the network structure of your company. The proxy server saves copies of the visited pages in the cache. Therefore, when these pages are revisited, the server loads these cached copies, providing faster access and reducing the load on the Internet connection. Proxy servers support multiple protocols such as HTTP, FTP, WAIS, Gopher, and HTTPS. Despite the advantages discussed here, there are certain disadvantages associated with proxy servers. The browser configuration is more complex and the added data trans-

JAVA AND FIREWALLS

Chapter 14

fers delay page access. Proxies impose restrictions on the length of a connection, thus preventing very large downloads. Refer to Figure 14-3 to understand the role of proxy servers.

FIGURE 14-3 The proxy server acts as an intermediary

SOCKS SOCKS is the shortened form of socket secure. The SOCKS protocol allows the users within a firewall to access all the services outside the firewall. However, it does not allow external users to access resources inside the firewall. A SOCKS gateway works through a TCP protocol called SOCKS along with the SOCKS server program running in the firewall system. The SOCKS gateway provides a way of encapsulating any TCP protocol with the SOCKS protocol. At the client end, the data packets sent to an external system are placed inside a SOCKS packet and sent to a SOCKS server. At the server end, when this data packet is received, the specified destination address, port, and data are extracted. The data is sent to the specified IP address of the SOCKS server. These packets from the SOCKS server program are not blocked by the firewall. Then, the data packets are returned from the SOCKS server to the original client. The client removes the SOCKS encapsulation and delivers the data to the requesting application. I’ve discussed the process of using the SOCKS protocol. Now, I’ll discuss the advantages and disadvantages of using it. The advantage is that a firewall can be configured easily. The firewall allows TCP/IP connection on any port from the SOCKS server to the Internet. However, any connections from the Internet are disallowed. The disadvantage is the modification of the client-end software to use SOCKS. The dynamically linked libraries implementing TCP calls are replaced by a SOCKSified version. These are then called the SOCKSified TCP/IP stacks. If these stacks are used with the client nodes, there is no need to modify the client. The client requires the following information: ◆ The SOCKS configuration specification ◆ The address of the SOCKS server ◆ Information about whether to use SOCKS or establish a direct connection

345

346

Part II


Therefore, you can provide secure Internet access by using corporate firewalls based on the proxy server and SOCKS gateway. Based on the company’s security needs, the network security manager can select any one of these. The Internet Explorer and Netscape browsers have built-in support for SOCKS and proxy servers. Using the SOCKSified stack is a much better option because you can decide whether to send a request to the SOCKS server. By sending all requests to the SOCKS server, it may become overloaded. This task is managed by a configuration file, which contains the addresses that are handled directly and the ones that need to go through the SOCKS server. This approach provides a simple way to run Java applets through firewalls by using a SOCKS server. Refer to Figure 14-4 to understand the role of SOCKS in a firewall scenario.

FIGURE 14-4 The role of SOCKS in a firewall scenario

I’ve already mentioned that Java programs are affected by firewalls when they are downloaded from a remote server or when they attempt to create network connections. Let’s discuss both these situations in more detail.

Downloading an Applet from a Remote Server A browser transfers the Java applets within a Web page by using the HTTP protocol. Then, the browser fetches the class files identified by the <APPLET> tag. Finally, the browser looks for any class files that have been referenced by the class files specified in the <APPLET> tag. These transfers are performed using the HTTP protocol. However, in Java 2, all the classes are stored in a compressed JAR file that is downloaded.

JAVA AND FIREWALLS

Chapter 14

How are these Java downloads affected by firewalls? You are already aware that data transfers in Java applets occur through the HTTP protocol. Therefore, if the security policy allows HTTP, the applets are also downloaded as other Web pages. However, if this protocol is not permitted, fetching the applet class files poses a problem. You then have to find other ways, such as FTP, to download them. To enable high-level security for Java applications, simple filtering based on port numbers and IP addresses is not sufficient. You need a suitable Web proxy server or gateway that implements checks before a data transfer occurs. By using Web proxy servers, you can force clients to go through the proxy via the firewall. All HTTP transfers are forbidden through the firewall. Therefore, users cannot connect directly, bypassing the access control checks forced by firewalls. If HTTP requests are made, products that perform inspection and check the HTTP requests that pass in through the firewall are required. While performing these checks, it is necessary to distinguish between trusted and untrusted code. For example, it should be possible to scan those applets that perform malicious tasks by invading the system. Besides the Java code, you also need to filter all the code that is less secure, such as JavaScript and ActiveX components. Another way of distinguishing between good and bad Java applets is to verify the sign on them. Users can take the decision to download and use a specified applet if they trust the signer of the applet. However, more restrictions should be placed on the Java code that is received by users. The users can also employ policies at their end to restrict untrusted Java applets.

Java Network Connections There are many security restrictions for Java applets when they try to establish network connections. In the case of applets, they can only establish network connections with the server from where they were downloaded. Generally, applets are downloaded through firewalls. However, when they try to connect back to the server, it is not allowed due to firewall restrictions. A malicious applet launches network security attacks on other computers. This is also possible without the use of Java applets. However, embedding an attack in a Java applet is easy as the attackers can launch this applet from an innocent user’s computer. However, if your firewall is well configured, attackers cannot use applets easily to launch network attacks. Other Web applications besides Java applets do not possess the powerful feature of establishing network connections. Using applets, you can create client-server applications effectively on the Internet. The main problem that these applets face is the existence of firewalls that proves to be a hindrance in maintaining constant network connections between the client and servers. Java applets are client applications that are

347

348

Part II


downloaded and run on computers that are protected by firewall networks. These applets try to connect to the server that is outside the client-side firewall. This can be done through the client-side proxy server. This is difficult because the applet has no knowledge of the proxy server and firewall composition at the client end. A Java applet can retrieve data from a Web server that is outside the client-side firewall by establishing a URL or socket connection. The URLConnection class requests a Web server that uses the HTTP protocol for data. The SocketConnection class creates socket connections to a dedicated server application. In the subsequent section, I’ll discuss how to write Java applications that connect with Web HTTP servers outside the client-end firewall.

Creating Java Applications that Work through Firewalls You can combine Java applications and proxy servers by activating certain system properties in the Java runtime. You need to specify proxy and user information in a Java application so that it can communicate with a proxy server. To provide this information, you need to add the following code statements in your Java program: System.getProperties().put(“proxySet”, “true”); System.getProperties().put(“proxyPort”, “85”); System.getProperties().put(“proxyHost”, “myProxy”);

I’ll explain the preceding code statements sequentially. The first statement indicates that you would be using a proxy server for establishing network connections. The second statement sets the proxy port to 85. The third statement specifies the host computer of the proxy server. There are situations when you need to enter a username and a password for accessing a Web server behind a corporate firewall. This authenticates a particular user for accessing the specific site. The connection can be established by using the URLConnection class. Observe the following code statements: URLConnection conn = url.OpenConnection(); String password = “username:password”; String encodePass = base64Encode(password); connection.setRequestProperty(“Authorize Proxy”, encodePass);

The preceding code statements use the setRequestProperty() method to adjust the HTTP header to release the user information. This method sets the general request property by modifying the HTTP headers before the request is sent. The password is encoded to the base-64 format because HTTP requires information in base-64-encoded format. Therefore, as seen in the preceding discussion, you need to add a few code statements to help your Java application communicate with the specified proxy server.

JAVA AND FIREWALLS

Chapter 14

You are already aware that applets can make a network connection only to the server from where they were downloaded. This prevents malicious applets from starting connections with uninformed hosts. Applets can connect to the server computer via an HTTP connection to the server program running on the server computer. They can also connect to the server program running on the server by using a socket connection. I’ll first discuss the operations to be performed when an applet needs to communicate with a server program using the HTTP protocol. The server creates a ServerSocket object and starts the accept connection call on a familiar port. The data to be transmitted from the client to the server is formatted as a URL message, and the URLConnection is made. When a connection is established and the server’s accept call succeeds, the server can read messages from the client and write back to the client. Each such transaction is followed by invoking the close() method on the socket connection object. With this, a single transaction with the server is completed. If there are more transactions, the preceding process is repeated. Let’s observe the code implementations for this process at the client end and server end.

The Client-end Implementation The client creates a base URL for the server from where the applet originated. It does this at the familiar port number on which the server performs the listen operation. The encoded message is appended to the base URL. Observe the following code: String MessageToServer = encode (“Sending message from client to server”); URL baseURL = new URL (“http://” + getCodeBase().getHost() + “:” + portNumber + “/”); URL myurl = new URL (baseURL, ServerMessage);

In the preceding code statements, a URL object is created that contains the base URL and server message. Now, let’s open a connection with the server by using the following code statements: DataInputStream din = new DataInputStream (new BufferedInputStream (myurl.openConnection().getInputStream()));

String ServerMessage; while ((ServerMessage = din.readLine()) != null) {

// Perform operations on the message } din.close ();

349

350

Part II


The preceding code statements use a while loop to read the message from the server in the data input stream. After all the data is read, the connection is closed.

NOTE The preceding code snippets depict only the basic code for the client end. However, when this code is practically implemented, error checking also needs to be performed. The proxy server throws errors when the specified message document contains no data or when the specified connection with the server cannot be established. These errors can also include timeout errors on the proxy.

In the subsequent section, I’ll discuss the skeleton code implementation at the server end.

The Server-end Implementation The server end starts its operations by creating a server socket on a familiar port number. The following code statement depicts this operation: ServerSocket MyServerSocket = new ServerSocket (portNumber);

Now, the server is ready to accept connections from the client. After the connection is established from the client end, the server reads the input sent by the client. Observe the following code statements that depict this: Socket MySocket = MyServerSocket.accept (); DataInputStream din = new DataInputStream( new BufferedInputStream (MySocket.getInputStream())); PrintStream psout = new PrintStream( new BufferedOutputStream (MySocket.getOutputStream()), true); String message = din.readLine();

Note that the client is communicating with the server by using the HTTP protocol only and does not want other connections on the specified port. The message string is prefixed with the GET keyword because the GET method is being used. This message is then encoded because the GET method does not allow any special characters or spaces. The server reads the client message and replies on the same connection. All communication should be preceded by the HTTP headers, informing the client-end proxy server that messages are in the valid HTTP format.

JAVA AND FIREWALLS

Chapter 14

The preceding discussion is implemented by the following skeleton code: static final String HTTP_PROTOCOL = “ HTTP/1.0”; static final String HTTP_CMD = “GET /”;

if (!message.endsWith(HTTP_PROTOCOL) || !message.startsWith (HTTP_CMD)) {

System.out.println (“Error in message”); din.close (); psout.close (); MySocket.close (); }

// Remove “GET /” at the beginning and “ HTTP/1.0” at the end of the message message = message.substring (HTTP_CMD.length (), message.length () - HTTP_PROTOCOL.length ());

// Decode the encoded string message = decode (message);

// Respond to the message by sending the standard headers psout.println (“HTTP/1.0 200 Server\r”); psout.println (“\r”);

// Print the original message psout.println (“Server message to client”); psout.close (); MySocket.close ();

The preceding sections discuss a situation when both the client and the server respond via the same connection. However, in a real-life scenario, you need a full-duplex connection between the client end and the server end. This connection allows the client and server to respond simultaneously.

351

352

Part II


Summary In this chapter, I discussed firewalls in brief. I also explained the interaction of programs through a firewall. Then, I discussed proxy servers and SOCKS gateways in brief. Next, I discussed that Java programs are affected by firewalls when they are downloaded from a remote server or when they attempt to create network connections. Finally, I explained the process of creating Java applications that work with firewalls.

Check Your Understanding Multiple Choice Questions 1. A request sent indirectly to the company’s server passes its firewall and goes to the server of the company from where it is transmitted to the secure company network. The company server is based on which of the following protocols? a. SOCKS b. HTTP c. TCP/IP d. Proxy server 2. What type of protocol allows the users within a firewall to access all the services outside the firewall, but does not allow external users to access resources inside the firewall? a. Proxy HTTP b. WAIS c. CGI d. SOCKS 3. To specify proxy and user information in a Java application so that it can communicate with a proxy server, which of the following code statements would you use in your Java program? a. System.getProperties().put(“proxySet”, “true”); b. System.getProperties().put(“proxyHost”, “myProxy”); c. connection.setRequestProperty(“Authorize Proxy”, encodePass); d. System.getProperties().put(“proxyPort”, “85”);

JAVA AND FIREWALLS

Chapter 14

Short Question 1. Consider a scenario in which any component of a secured network running on a Java-enabled browser with no Java plug-ins is attacked by using a malicious applet. This component resides on the victim’s computer: secure.victim.org (IP address 10.10.10.2). The attacker has a computer: www.attack.org (IP address 172.16.16.16). Explain the entire process of the attack and why the firewall on the victim’s end cannot avoid this attack.

Answers Multiple Choice Answers 1. d. Instead of sending a request directly to the company’s server, the request passes the firewall and goes to the proxy server of the company, at which point it is transmitted to the secure company network. 2. d. The SOCKS protocol allows users within a firewall to access all the services outside the firewall. However, it does not allow external users to get inside through the firewall. 3. a, b, and d. The first statement indicates that you would be using a proxy server for establishing network connections. The second statement specifies the host computer of the proxy server. The fourth statement sets the proxy port to 85.

Short Answer 1. The victim has a firewall that prevents computers that are external to the victim’s organization from making unauthorized network connections to the victim’s computer. Therefore, there can be no direct attack on the victim’s computer. The victim’s security depends entirely on this firewall. Then, how does the attacker surpass this firewall? The attacker creates a fake computer name, fake.attack.org, and creates a DNS mapping from fake.attack.org to the pair of IP addresses (10.10.10.2, 172.16.16.16). Then, the attacker creates a harmless-looking Java applet and attaches it to a Web page on www.attack.org. The victim visits this Web page on www.attack.org. This loads the attacker’s applet in the victim’s browser and starts executing the applet. On the front, the applet performs some harmless function that is visible to the victim. However, the applet also silently attacks the victim’s computer. This attack is not visible to the victim. First,

353

354

Part II


the applet requests to create a network connection to fake.attack.org. The Java system looks up the address fake.attack.org, and fetches the IP address pair (10.10.10.2, 172.16.16.16). The Java system compares this address pair to the address of the computer that the applet originated from (172.16.16.16). This is the IP address of the attacker’s computer. Because the two computers have the common address 172.16.16.16, Java allows the connection. However, the Java system actually connects to the first address on the list, namely 10.10.10.2. This is the IP address of the victim’s computer (target.victim.org). The attacker’s applet now has a network connection to the victim’s computer. Now, it can attack the defenses of the target.victim.org computer. The attack is successful because the victim’s firewall could not prevent it. This is because the dangerous network connections originate from the victim’s own computer. In such a case, the firewall is rendered useless. Moreover, the attacker causes the victim’s own Web browser to attack the victim’s computer.

Chapter 15 Java and SSL

n Chapter 8, “Security Configuration Files and Security APIs,” and in Chapter 12, “An Introduction to Cryptography,” I discussed that you can invoke cryptographic functions within Java code. For implementing these functions, you need cryptographic protocols. In this chapter, I discuss Secure Socket Layer (SSL), which is a protocol used for transmitting encrypted data between a client and a server. This protocol operates over TCP/IP. In this chapter, I provide a brief overview of the SSL protocol. I also discuss Java APIs that support SSL. Finally, I discuss the usage of Java and SSL.

I

An Overview of SSL SSL is a communications layer protocol that rests atop the TCP/IP protocol stack. It has been created by Netscape Communications Corporation and is used for implementing cryptographic functions and transmitting encrypted data through a secure connection. It can also operate under other protocols such as HTTP. Therefore, you can imagine SSL as a layer between TCP/IP and high-level protocols such as HTTP. This layer aids in providing a secure communication mechanism. In cryptographic implementation, SSL authenticates both the server and the client that use digital certificates and public key signatures. However, this authentication is optional and depends on client and server requirements. SSL provides a communication passage between a server and a client for encrypted messages to be transmitted securely. SSL uses symmetric cryptography for encrypting data and asymmetric cryptography for authenticating the client and the server after an SSL session is established. SSL also encrypts a shared key that can be transmitted at both the client- and the server-end in a secure way. The client and the server encrypt and decrypt the messages by using this shared key. SSL provides privacy to communication flows by encrypting data and enabling the safe transfer of important information such as passwords or credit card numbers. There is a secure hash function built in the SSL protocol that checks data integrity, thus ruling out the possibility of data corruption. SSL enables server authentication by the client-side and vice versa. However, client authentication by the server is optional. Therefore, by using SSL, the data transfer is between recognized parties. The communication between parties can be proved with the use of digital signatures and certificates.

JAVA AND SSL

Chapter 15

The SSL protocol includes two subprotocols, the SSL record protocol and the SSL handshake protocol. The record protocol determines the format in which data transmission takes place. The handshake protocol uses the record protocol to exchange messages between a client and a server after an SSL connection is established. SSL uses different cryptographic algorithms or ciphers for performing its authentication and encryption operations. The clients and servers support different sets of ciphers referred to as cipher suites. The handshake protocol also determines how the server and the client agree on specific cipher suites that they will use for authentication, establishing a session, and transmitting messages. The cipher suites can include algorithms such as DSA, RSA, MD5, and SHA-1. SSL uses key exchange algorithms such as KES and RSA to determine the symmetric keys used by a client and a server during an SSL session. The SSL cipher suites generally use RSA key exchange.

The SSL Handshake An SSL session begins with the exchange of encrypted messages. This is called an SSL handshake. The handshake begins by performing server authentication for the client by using public-key techniques. It then allows the client and the server to agree upon a symmetric key that is used for encryption and decryption during the session. The handshake also allows client authentication for the server. However, this is optional. The steps involved in an SSL handshake are summarized here: 1. An SSL client connects to the SSL server. 2. The client sends a ‘hello’ message to the server. The message contains the SSL version number, the cipher settings, and randomly generated data. 3. The server responds to the client with a ‘hello’ message that includes its SSL version number, the cipher settings, and randomly generated data. The server also sends its certificate to the client. If the client has requested a server resource that requires client authentication, the message also includes a request for the client’s certificate. 4. The client authenticates the server by using the server certificate. It checks the certificate for validity, determines whether the signature is by a trusted CA, and verifies the signature. If the client encounters a problem while authenticating the server, the user is informed that an encrypted or authenticated connection cannot be established. If there is no problem in server authentication, it moves to the next step.

357

358

Part II


5. The client with server cooperation creates a premaster secret key and encrypts it with the server’s public key. It obtains the public key from the server certificate. 6. If the server has requested for client authentication, which is optional, the client sends its certificate, a signed piece of data, and the encrypted premaster secret key to the server. 7. The server authenticates the client by using the client certificate. It checks the certificate for validity, determines whether the signature is by a trusted CA, and verifies the signature. If there is a problem in client authentication, the session is terminated. If the client is successfully authenticated, the client and the server use the premaster secret to generate a master secret. 8. The client and the server generate session keys by using the master secret. These are symmetric keys and are used to encrypt and decrypt the information transferred in the SSL session. 9. The client and the server exchange cipher specification messages, which indicate that any further messages would be encrypted by using the secret session keys. 10. The client and the server exchange encrypted messages, indicating that the respective portion of the handshake on both the ends is complete. 11. The SSL handshake is complete, and the SSL session has started. The client and the server use the session keys to encrypt and decrypt the data sent to each other. They also use the session keys to check the integrity of the messages.

NOTE While performing server authentication, the client encrypts the premaster secret with the server’s public key. The premaster secret can be correctly decrypted only with the corresponding private key. Therefore, the client positively knows that the identity associated with the public key is the server with which the client is connected. If the server cannot decrypt the premaster secret, it cannot generate the symmetric keys required for the SSL session. In such a case, the session is terminated. The same holds true for client authentication in which the client encrypts some random data by using its private key. Only the public key in the client’s certificate can correctly validate this data. If the server cannot validate the data, the session is terminated.

JAVA AND SSL

Chapter 15

Java can utilize the SSL protocol by using either the built-in SSL support in the browser or an SSL package.

SSL Support in Browsers When a Web administrator wants the users of a specific site to start an SSL connection, the administrator uses https instead of http in the URL name. When a user accesses this link, the browser automatically invokes the SSL handshake and connects to the default SSL port on the server. All the relative links on an SSL page are also retrieved using SSL. When a user retrieves an applet over an SSL connection, the user knows that it is a trusted applet. This is possible because of the server authentication process during the SSL handshake. Until now, only the files or applets that were signed were considered trusted. However, the location from where they were downloaded could not be trusted completely. Now, by transferring signed JAR files or applets via an SSL connection, even the site or the server from where they are downloaded can be trusted. The preceding approach is a simple one. However, it cannot exploit the capabilities imposed by a direct SSL socket connection between a client and a server. Such a connection enables you to create more complicated applets that are quick to respond. In the subsequent section, I’ll discuss the Java APIs that allow such a direct SSL socket connection.

An Overview of Java Secure Socket Extension (JSSE) Java Secure Socket Extension ( JSSE) is a set of packages that provides a standard API to establish secure Internet communications. This extension implements a Java version of the SSL protocol for server authentication, message encryption, message integrity, and optional client authentication. Therefore, using JSSE, developers can create Java programs that provide a secure and encrypted communication channel between a client and a server.

359

360

Part II


JSSE 1.0.2 provides SSL v3 and Transport Layer Security (TLS) 1.0 support to the Java 2 platform. JSSE consists of the following packages: ◆

The javax.net package contains optional classes for networking applications. ◆ The javax.net.ssl package contains the core classes and interfaces that are specific to the JSSE APIs. ◆ The javax.security.cert package contains the classes that provide support for certificate management. I’ll discuss each of these packages in detail in the subsequent sections.

The javax.net Package This package is not specific to SSL. It contains the ServerSocketFactory and SocketFactory classes. The ServerSocketFactory class creates server sockets. It provides a framework for socket-level functionality. The SocketFactory class creates sockets and provides a framework for socket-level functionality. Socket factories capture the policies related to the sockets being constructed and produce sockets that do not require the configuration of code.

The javax.net.ssl Package This package contains the classes that support communication by using SSL. This class contains the interfaces, classes, and exceptions that are discussed in the subsequent section. This package supports features such as SSL sockets, SSL server sockets, SSL socket factories, SSL session requirements, the handshake completion facility, and SSL-specific exceptions. The preceding features are supported by four interfaces, six classes, and five exceptions.

The Interfaces in the javax.net.ssl Package The following list describes the interfaces in the javax.net.ssl package: ◆

The HandshakeCompletedListener interface is implemented by the classes that want to receive an indication about the completion of an SSL protocol handshake. ◆ The SSLSession interface is used to represent the objects that describe the client and server status in an SSL connection.

JAVA AND SSL

Chapter 15

◆

The SSLSessionBindingListener interface is implemented by the objects that need to be informed of the SSL session binding and unbinding events.

◆

The SSLSessionContext interface is implemented by the objects that contain a collection of SSL sessions, which are identified by a specific session ID.

The Classes in the javax.net.ssl Package The following list describes the classes in the javax.net.ssl package: ◆

The HandshakeCompletedEvent class indicates the completion of a handshake on a given SSL connection.

◆

The SSLServerSocket class represents the server sockets that return the connections protected by the SSL protocol.

◆

The SSLServerSocketFactory class creates SSL server sockets.

◆

The SSLSessionBindingEvent class creates an event object that is sent to an object that implements the SSLSessionBindingListener interface when the listener is bound or unbound from an SSLSession value.

◆

The SSLSocket class is extended by the sockets that support the SSL and TLS protocols.

◆

The SSLSocketFactory class implements SSL sockets.

The Exceptions in the javax.net.ssl Package The following list describes the exceptions in the javax.net.ssl package: ◆ SSLException

represents an error detected by an SSL subsystem.

◆ SSLHandshakeException

indicates that the client and the server could not agree on a desired security specification.

◆ SSLKeyException

indicates an incorrect SSL key generated due to a configuration mismatch of the server or the client SSL certificate and the private key.

◆ SSLPeerUnverifiedException

indicates that the peer’s identity requested by a user is not verified. This exception is raised when the peer cannot identify itself by presenting proof such as a certificate or peer authentication.

◆ SSLProtocolException

indicates an error in SSL implementation.

361

362

Part II


The javax.security.cert Package This package contains the following classes and exceptions: ◆

The Certificate class is used for managing identity certificates. Certificates such as X.509, Simple Distributed Security Infrastructure (SDSI), and Pretty Good Privacy (PGP) can be implemented by creating subclasses from the Certificate class. This is possible even though they contain information in different formats and the way of storing and retrieving this information is also different. However, they share functionality such as encoding and verifying. They also share information such as public keys.

◆

The X509Certificate class is a class for X.509 V1 certificates and provides an implementation for using the Version 1 attributes of these certificates.

◆

The CertificateException class is used to indicate any error occurring with certificates.

◆

The CertificateEncodingException class is used to represent an error occurring while encoding a certificate.

◆

The CertificateNotYetValidException class is used to throw an exception when the certificate is not yet valid. This is thrown when the current Date or the specified Date is before the notBefore date/time in the validity period of the certificate.

◆

The CertificateExpiredException class is used to throw an exception whenever the current Date or the specified Date is after the notAfter date/time specified in the validity period of the certificate.

◆

The CertificateParsingException class is used to throw exceptions while parsing an invalid DER-encoded certificate.

You have read about all the packages in JSSE. Now, I’ll discuss the use of Java and SSL.

Using Java and SSL In the subsequent sections, I’ll discuss the methods of the various SSL classes in JSSE that are used for implementing an SSL session in Java. The sections cover the setting of JSSE providers, creating SSL server sockets, creating client SSL sockets, establishing a connection between a client and a server, and transferring

JAVA AND SSL

Chapter 15

encrypted data via this connection. After the SSL handshake is complete, an SSL session is established. This SSL session has certain parameters and properties that can be set by using various Java APIs. I’ll also discuss these APIs in the subsequent sections.

JSSE Providers You can configure JSSE providers as you configure the other providers in Java by adding or modifying an entry in the java.security file. Consider the code statement given here: security.provider.3 = com.Myweb.security.SSLProvider

There is another method of configuring a JSSE provider by using the java.security.Security class. You can define a provider and add it by using the addProvider() method of the Security class. For example, consider the code here: java.security.Provider myProvider = new com.sun.net.ssl.internal.ssl.Provider(); java.security.Security.addProvider(myProvider);

is the default SSL provider that comes with the downloaded JSSE implementation. This provider supports SSL v3 and TLS v1. It also supports PKCS12 keystores, the X.509 key management functionality, and RSA encryption. Now, let’s discuss SSL server sockets in the JSSE implementation.

com.sun.net.ssl.internal.ssl.Provider()

SSL Server Sockets You can create SSL server sockets as you create ordinary server sockets in Java. These server sockets provide the implementation for authentication, the cipher parameters, managing handshaking operations, and establishing sockets for an SSL session. In the subsequent section, I’ll discuss the steps for creating SSL server socket factories. You can manipulate the sockets in SSL as you manipulate the other TCP/IP sockets.

Creating an SSL Server Socket Factory You can create general server sockets by using the javax.net.ServerSocketFactory class. In JSSE, SSL sockets are implemented by using this concept of general sockets. The javax.net.ssl.SSLServerSocketFactory class is a subclass of the ServerSocketFactory class and is used to create SSL server sockets. The default

363

364

Part II


server socket in JSSE can be created by invoking the getDefault() method of the SSLServerSocketFactory class, as shown here: javax.net.ssl.SSLServerSocketFactory sslServerSocket = SSLServerSocketFactory.getDefault();

This method needs the default server socket factory class name that is present in the java.security file. The JSSE providers can also supply server authentication information. This can be done by using the com.sun.net.ssl.SSLContext class, which is used to obtain context information about the SSLServerSocketFactory objects. However, before this, you need to configure SSL server sockets with certain security properties. These properties include the KeyManager, TrustManager, and SecureRandom objects. These objects are also used to initialize the properties of the SSLServerSocketFactory class. The entire process of creating these objects and initializing SSL server sockets is specified in the following code listing: // A keystore object is created to store server certificates and keys. // This keystore is based on the “jks” keystore type and has the name, myStore. Keystore keyStore = null; try{ String type = “JKS”; keyStore = KeyStore.getInstance(type); // Generate a keystore file stream String keyStoreFileName = “myStore”; FileInputStream fis = new FileInputStream(keyStoreFileName); // Load the keystore from the input stream. // You’ll have to provide the keystore password. String password = “popiujyt”; char[] charPassword = password.toCharArray(); keyStore.load(fis, charPassword); } catch(Exception e){ System.out.println(e); System.exit(0); }

The preceding code listing creates a keystore object. Now, I’ll create KeyManager objects based on the keystore created. The KeyManager interface manages the key material that is used to authenticate an SSL socket to its peer. If these keys are not available, the server socket will not be able to submit its authentication details.

JAVA AND SSL

Chapter 15

Refer to the following code for creating X.509 key managers. You can use the com.sun.net.ssl.KeyManager class for this purpose. KeyManager[] km = null; try{ //Use the specified algorithm to create a key manager factory. String algorithm = “SunX509”; KeyManagerFactory kmf = KeyManagerFactory.getInstance(algorithm); // Initialize this key factory with a specified password // and the keystore defined in the preceding listing String kmPassword = “jfgkjsgfs”; kmf.init(KS, kmPassword.toCharArray()); // Derive key managers from this factory km = kmf.getKeyManagers(); } catch(Exception e){ System.out.println(e); System.exit(0); }

Now, I’ll create TrustManager objects. Trust managers manage the trust material that is used when making trust decisions between a server and a client in an SSL session. They also decide whether the credentials presented by a peer should be accepted. They are created by using TrustManagerFactory. Refer to the following code for creating TrustManager objects. You can use the com.sun.net.ssl.TrustManager class for the same. TrustManager[] tm = null; try{ //Use the specified algorithm to create a trust manager factory. String algorithm = “SunX509”; TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); // Initialize this key factory with the keystore // defined in the preceding listing. tmf.init(KS); // Derive trust managers from this factory. tm = tmf.getTrustManagers(); } catch(Exception e){

365

366

Part II


System.out.println(e); System.exit(0); }

Finally, I’ll create the last security property needed, SecureRandom objects. This class provides a cryptographic Pseudo-Random Number Generator (PRNG). The SecureRandom class provides implementation-independent algorithms for creating objects. The random values created by this class are used in the implementation of the SSLContext object. Refer to the following code for creating SecureRandom objects: SecureRandom sr = null; try{ // Create a SecureRandom object by using the specified algorithm // and provider. String algorithm = “SHA1PRNG”; String provider = “SUN”; sr = SecureRandom.getInstance(algorithm, provider); } catch(Exception e){ System.out.println(e); System.exit(0); }

Now, as I’ve created the KeyManager, TrustManager, and SecureRandom objects, let’s see how to create and initialize the SSLContext object. SSLContext context = null; try{ // Specify the context provider String provider = “SUN”; context = SSLContext.getInstance(provider); // Initialize the context object context.init(km, tm, sr); } catch(Exception e){ System.out.println(e); System.exit(0); }

JAVA AND SSL

Chapter 15

Now, let’s create an SSLServerSocketFactory object. SSLServerSocketFactory sslServerSocketFactory = context.getServerSocketFactory();

Now, since you have the SSLServerSocketFactory object in place, you can create SSL server sockets. The subsequent section discusses this.

Creating SSL Server Sockets SSL server sockets can be created by using the createServerSocket() methods of the ServerSocketFactory class. These methods return server socket objects that are instantiated from the subclasses of the SSLServerSocket class. These three methods are overloaded and the different method definitions are given here: ◆ The createServerSocket(int port)

method returns a server socket

bound to the specified port. ◆

The createServerSocket(int port, int backlog) method returns a server socket bound to the specified port and using the specified connection backlog.

◆

The createServerSocket(int port, int backlog, InetAddress ifAddress) method returns a server socket bound to the specified port and with the specified connection backlog and IP address.

Consider the code given here: // Create an SSL server socket by using the SSL server socket factory try{ // Specify the server port int port = 890; SSLServerSocket sslSerSocket = (SSLServerSocket) sslServerSocketFactory.createServerSocket(port); } catch(Exception e){ System.out.println(e); System.exit(0); }

The preceding code creates an SSL server socket by using the specified port number. Once the SSL server socket is created, it listens for client requests. I’ll discuss this in the subsequent section.

367

368

Part II


Listening for Client Requests To listen to client requests, you can use the accept() method of the SSLServerSocket class. This method returns a Socket object, indicating the socket connection with the client that made the request. You can then typecast this object to an SSLSocket object and use it for SSL-related operations. Consider the code given here: try{ // Wait for client requests and then hand // over the client sockets to a thread for manipulation while(true){ SSLSocket clientSocket = (SSLSocket) sslSerSocket.accept(); MyThread connthread = new MyThread(clientSocket); //Start executing the thread connthread.start(); } } catch(Exception e){ System.out.println(e); System.exit(0); }

In the preceding code, you see a new class, MyThread. Let’s observe the definition of this class that handles client requests by using socket calls and I/O stream handling. The code definition of the MyThread class is given here: // This class definition shows the code for only the necessary methods. public class MyThread extends Thread { private InputStream is; private OutputStream os; private Socket sslSocket; // Code statements here……. public MyThread(SSLSocket sslsocket) throws IOException { this.sslSocket = sslSocket; this.os = sslSocket.getOutputStream(); this.is = sslSocket.getInputStream(); } // Code the run method for the thread

JAVA AND SSL

Chapter 15

public void run() { try{ DataInputStream dis = new DataInputStream(is); String read = null; // Read a line from the input stream while((read = dis.readLine())==null) System.out.println(read); // Set the read variable to the next line in the input stream read = dis.readLine(); System.out.println(read); // Other code statements } catch (IOException e){ System.out.println(e); } }

The preceding class listens to the requests placed by client computers by using input streams and maintaining socket connections.

Client Authentication Client authentication can be implemented on the server side by using the setNeedClientAuth() and getNeedClientAuth() methods of the SSLServerSocket class. The method definition of setNeedClientAuth() is given here: public abstract void setNeedClientAuth(boolean flag)

This method determines whether the accepted socket connections must include client authentication. However, this option is only for sockets in the server mode. The SSLSocket objects returned from the accept() method use this method. The method definition of the getNeedClientAuth() method is given here: public abstract boolean getNeedClientAuth()

If client authentication is required for accepted connections, this method returns true. If the server requires client authentication, the SSL client needs to provide certificate information.

369

370

Part II


Until now, I’ve discussed the creation of sockets from a server to a client. In the subsequent section, let’s discuss the creation of sockets from a client to a server by using JSSE.

SSL Client Sockets Clients can create sockets by using SSL socket factories as SSL servers create sockets by using SSL server socket factories. The client SSL sockets are then used as you use ordinary Java sockets to establish connections with a remote server. I’ve already discussed the creation of SSL server sockets in the preceding section. Now, let’s discuss the creation of SSL client sockets.

Creating an SSL Socket Factory You can use the SSLSocketFactory class to create SSL sockets for clients. This class extends from the SocketFactory class. The process of creating client sockets is either through JSSE providers or by using the default SSLSocketFactory class configured in the client’s environment. The process of creating client sockets by using JSSE providers is similar to that used for server sockets with one exception—the following method call must be made when all the security parameters are set. SSLContext context = SSLContext.getInstance(“SUN”);

You then establish all the security parameters and initialize the SSLContext object. The SSLSocketFactory object can be created as shown here: SSLSocketFactory sslSocketFactory = context.getSocketFactory();

The client’s environment can have a default SSLSocketFactory class configured in the java.security file by setting the ssl.SocketFactory.provider property, as shown here: ssl.SocketFactory.provider=com.myweb.ssl.SocketFactory

To obtain the default SSLSocketFactory class, you need to call the getDefault() method, as shown here: SSLSocketFactory sslSocketFactory = (SSLSocketFactory) SSLSocketFactory.getDefault();

Now, you have seen how to create an SSL socket factory. In the subsequent section, let’s discuss ways of creating SSL sockets by using this socket factory.

JAVA AND SSL

Chapter 15

Creating SSL Client Sockets The SSLSocketFactory class defines four createSocket() methods that are inherited from the SocketFactory class. The subclass, SSLSocketFactory, defines another createSocket() method. These methods are listed here: ◆

The createSocket(String host, int port) method creates a socket and connects it to the specified host and port.

◆

The createSocket(String host, int port, InetAddress localHost, int localPort) method creates a socket and connects it to the specified server host and server port. The socket will also be bound to the local address and the port supplied.

◆

The createSocket(InetAddress host, int port) method creates a socket and connects it to the specified port at the specified address.

◆

The createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) method creates a socket and connects it to the specified server host and server port. The socket will also be bound to the local address and the port supplied.

The SSLSocketFactory class defines another createSocket() method, which is listed here: public abstract Socket createSocket (Socket s, String host, int port, boolean autoClose) throws IOException

This method creates a socket that is layered over an existing socket that is connected to the specified host at the specified port. This method is used for establishing SSL over an existing socket connection. If the created SSL socket is closed, the underlying socket is also closed. This closing status is decided by the Boolean parameter, autoClose. Let’s create a sample socket by using this method: String host = “172.16.16.16”; String port = 80; // Create an SSLSocket object at the specified host address and port. SSLSocket sslSocket = (SSLSocket) sslSocketFactory.createSocket(host, port);

In the preceding code, the value returned by the createSocket() method is typecast. This is because all these methods return a Socket object, whereas I need an SSLSocket object.

371

372

Part II


Therefore, in the preceding sections, I’ve discussed the creation of SSL server and client sockets. Once a connection is established between the client and the server, the encryption and decryption of data occurs by using the InputStream and OutputStream objects. These objects are used to receive and send data across the connection. Now, an SSL session is established between the client and the server. I’ll discuss the properties of this SSL session in the subsequent section. SSL sessions are represented by the SSLSession interface.

The SSLSession Interface In the SSL protocol, a session represents a relationship between two communicating identities. There is one SSL session on each SSL connection established. However, this session can be simultaneously used on multiple connections between two identities. A session on a particular connection can also be replaced by another session. The server sockets created by using the SSLServerSocket class contain the setEnableSessionCreation(boolean flag) method, which controls whether new SSL sessions can be created by these server sockets. If the flag parameter is true, it indicates that an SSL session can be established. The SSLServerSocket class also contains the boolean getEnableSessionCreation() method that returns a true value if the particular SSL server socket enables the creation of a session. Let’s discuss the methods in the SSLSession interface.

The getID() Method The method definition is given here: public byte[] getId()

This method returns an identifier associated with a particular session.

The getSessionContext() Method The method definition is given here: public SSLSessionContext getSessionContext()

JAVA AND SSL

Chapter 15

This method returns an SSLSessionContext object representing the context of a particular session. If the context is unavailable, this method returns null. The specified context can be made available only when the security manager grants the associated permission.

The getCreationTime() Method The method definition is given here: public long getCreationTime()

This method returns a long value that represents the time when the particular session was created. The time is measured in milliseconds from January 1, 1970.

The getLastAccessedTime() Method The method definition is given here: public long getLastAccessedTime()

This method returns a long value indicating when the session was last used. Operations such as getting or setting certain values in an application are not accounted for in this access time. The time is measured in milliseconds from January 1, 1970.

The invalidate() Method The method definition is given here: public void invalidate()

This method is used to invalidate the current session, debarring other connections from using the current SSL session. Any existing connection using this session can continue to do so until the session is closed.

The putValue() Method The method definition is given here: public void putValue(String name, Object value)

This method binds the specified object with the session using the specified name. If a particular binding with a similar name is already present, it is replaced. Different access control contexts cannot see the same named values due to security reasons.

373

374

Part II


The getValue() Method The method definition is given here: public Object getValue(String name)

This method returns an object value bound to the specified name in a particular session. If the binding does not exist, it returns a null value.

The removeValue() Method The method definition is given here: public void removeValue(String name)

This method removes the object represented by the specified name parameter. If there is no object bound to the specified name, the method returns silently and does not do anything.

The getValueNames() Method The method definition is given here: public String[] getValueNames()

This method returns a String array representing the names of all the objects bound to the specified session.

The getLocalCertificates() Method The method definition is given here: public Certificate[] getLocalCertificates()

This method returns a Certificate array representing the certificates sent to the peer during the handshaking operation. During the handshaking operation, if multiple certificate chains are available, the chain considered the best is sent to the peer. Therefore, this method returns the chain that was used for authentication purposes.

The getPeerCertificates() Method The method definition is given here: public Certificate[] getPeerCertificates() throws SSLPeerUnverifiedException

JAVA AND SSL

Chapter 15

When identifying the session, you set a remote peer for the session. This method returns a chain of certificates associated with this peer. SSLPeerUnverifiedException is thrown if the peer identity is not verified.

The getPeerCertificateChain() Method The method definition is given here: public X509Certificate[] getPeerCertificateChain() throws SSLPeerUnverifiedException

This method returns an array of the X.509 certificates associated with the remote peer of a particular session.

The getCipherSuite() Method The method definition is given here: public String getCipherSuite()

This method returns the name of the cipher suite that is used to establish connections in a particular SSL session. The cipher suite identifies the protection level for the data sent via a connection. It also decides the kind of encryption and the process of authentication.

The getPeerHost() Method The method definition is given here: public String getPeerHost()

This method returns the hostname of the remote peer in a specific session. The name returned is not a fully qualified peer name. Instead, it is a string representing the peer’s network address. In the case of the server, it is the client’s hostname. The reverse is also true. However, this value isn’t reliable because no authentication check is performed on this value.

The getProtocol() Method The method definition is given here: public String getProtocol()

375

376

Part II


This method returns the name of the protocol used for establishing connections in a specific SSL session. Therefore, all the preceding methods together specify all the properties of an SSL session.

The SSLSessionContext Interface This interface represents a set of SSLSession objects associated with a particular entity. For example, there can be a server or a client that participates in multiple sessions at the same time. However, there are environments that do not support such concurrent behavior. Therefore, in such a case, there will be no session contexts. The number of sessions that are stored in a given session context is limited, and the sessions can be set to expire after a given time limit. Moreover, a particular session can be listed by its ID in a given session context. These operations can be performed by the following methods of the SSLSessionContext interface: ◆

The getSession(byte[] sessionId) method returns an SSL session bound to the specified session ID.

◆

The getIds() method returns an enumeration of all the session IDs grouped within a particular SSL session context.

◆

The getSessionCacheSize() method returns the size of the cache that stores the SSL sessions within a particular session context.

◆

The setSessionCacheSize(int size) method sets the size of the cache for storing the SSLSession objects within a particular context. The size is passed as a parameter.

◆

The getSessionTimeout() method returns the timeout limit of the SSLSession objects grouped within this context.

◆

The setSessionTimeout(int seconds) method sets the timeout limit of SSLSession objects grouped within this context.

Summary In this chapter, I discussed SSL in brief. I explained the entire SSL handshake operation. Java can utilize the SSL protocol by using either the built-in SSL support in the browser or an SSL package. I described both these methods in detail. I also discussed the different packages in JSSE. Then, I described how to use SSL

JAVA AND SSL

Chapter 15

in Java. I talked about JSSE providers. I explained the methods of creating SSL server and client sockets. Finally, I discussed the SSLSession and SSLSessionContext interface.

Check Your Understanding Multiple Choice Questions 1. Which of the following statements describe SSL correctly? a. SSL was created by Microsoft. b. There is no SSL support in Netscape Navigator. c. SSL is a layer between TCP/IP and the high-level protocols such as HTTP. d. SSL transmits encrypted data through a secure connection. 2. Which of the following statements about an SSL handshake operation is true? a. Server authentication is optional. b. Even if there is a problem in client authentication, an SSL handshake proceeds. c. The client and the server generate session keys by using the master secret. d. An SSL session is complete after the handshake is over. 3. In which of the following ways can you configure a JSSE provider? a. Using the java.security file b. Using the addProvider() method c. Using the getDefault() method d. Using the Provider() method 4. Which of the following objects are needed to configure SSL server sockets with certain security properties? a. KeyManager b. TrustManager c. KeyStore d. SecureRandom

377

378

Part II


5. Which of the following methods is used to listen to client requests? a. accept() b. getProtocol() c. start() d. getInstance() 6. Which of the following statements about the invalidate() method is true? a. This method is used to invalidate the current session. b. All the existing connections are stopped. c. New connections cannot be made by using the current SSL session. d. All future sessions between the client and the server are invalidated.

Short Questions 1. What are the different ways of configuring JSSE providers? 2. Explain how Java can utilize the built-in SSL support in a browser.

Answers Multiple Choice Answers 1. c and d. SSL is used for implementing cryptographic functions and transmitting encrypted data through a secure connection. It can also operate under other protocols such as HTTP. Therefore, you can imagine SSL as a layer between TCP/IP and high-level protocols such as HTTP. This layer aids in providing a secure communication mechanism. 2. c. The client and the server use the premaster secret to generate a master secret. They generate session keys by using the master secret. These are symmetric keys and are used to encrypt and decrypt the information transferred in the SSL session. 3. a and b. You can configure JSSE providers as you configure other providers in Java by adding or modifying an entry in the java.security file. You can define a provider and add it by using the addProvider() method of the Security class.

JAVA AND SSL

Chapter 15

4. a, b and d. Before creating SSL server sockets, you need to configure the SSL server sockets with certain security properties. These properties include the KeyManager, TrustManager, and SecureRandom objects. 5. a. To listen to client requests, you can use the accept() method of the SSLServerSocket class. 6. a and c. The invalidate() method is used to invalidate the current session, debarring other connections from using the current SSL session. Any existing connection using this session can continue to do so until the session is closed.

Short Answers 1. You can configure JSSE providers as you configure the other providers in Java by adding or modifying an entry in the java.security file. Consider the code statement given here: security.provider.3 = com.Myweb.security.SSLProvider

There is another method of configuring a JSSE provider by using the java.security.Security class. You can define a provider and add it by using the addProvider() method of the Security class. For example, consider the code here: java.security.Provider myProvider = new com.sun.net.ssl.internal.ssl.Provider(); java.security.Security.addProvider(myProvider);

is the default SSL provider that comes with the downloaded JSSE implementation. This provider supports SSL v3 and TLS v1. It also supports PKCS12 keystores, the X.509 key management functionality, and RSA encryption.

com.sun.net.ssl.internal.ssl.Provider()

2. When a Web administrator wants the users of a specific site to start an SSL connection, the administrator uses HTTPS instead of HTTP in the URL name. When a user accesses this link, the browser automatically invokes the SSL handshake and connects to the default SSL port on the server. All the relative links on an SSL page are also retrieved using SSL. When a user retrieves an applet over an SSL connection, he/she knows that it is a trusted applet. This is possible because of the

379

380

Part II


server authentication process during the SSL handshake. Until now, only the files or applets that were signed were considered trusted. However, the location from where they were downloaded could not be trusted completely. Now, by transferring signed JAR files or applets via an SSL connection, even the site or the server from where they are downloaded can be trusted. This approach cannot exploit the capabilities imposed by a direct SSL socket connection between a client and a server. Such a connection enables you to create more complicated applets that are quick to respond.

III

PART

Appendixes


Appendix A Best Practices

I

n this appendix, I’ll discuss certain best practices or rules to be kept in mind while writing secure Java code. However, these best practices or rules do not guarantee that your code is secure and devoid of any attacks. This indicates that Java also contains loopholes that can pose as security risks. These rules are listed in the following sections.

Limiting Access You should limit the access to classes and methods in your code. Every class or method defined as public provides full access to an attacker to invade your system. You should make it a practice to declare everything as private by default. You should think twice before declaring anything as public. You should reason why a particular class or method needs to be declared as public. Ask yourself whether the code will function in the same manner if the class members are declared as private. If the answer is yes, declare the respective class members as private.

Handling Static Variables The next rule is to handle static variables carefully. You can create a class to verify that an object is initialized before it is used. You can do this by adding an initialize variable that is private and supports the boolean data type. All constructors should set this variable before returning to the actual code. It is a good practice to declare all variables as private. The external code should access the variables in an object by using the respective get and set methods. Check that the initialize variable is true before performing actions on the variable.

Avoiding Dependencies on Package Scope You already know that the classes or methods that are not specified as public, private, or protected can be accessed from the methods defined in the same package. Methods from an external package cannot access these. But, this is not enough to prove that the specific class or method is secure from attackers. An attacker can very easily code a method that is added to the same package as the class and access the data of the class. Therefore, a package is prone to such attacks. Certain JVM implementations allow you to close packages. The package scope—in terms of public, private, and protected — is not sufficient to implement complete security.

BEST PRACTICES

Appendix A

Declaring Final Classes or Methods It is a good practice to declare a class as final after its definition is finalized from your side. If a class is left open, that is, it is not declared as final, it provides opportunities to attackers to add their own code and extend your class definition. This rule specifies that classes should not be extensible. Only those classes should be declared as extensible where creating subclasses is very important for the Java program. Above all, as you read in the preceding section, you cannot rely on package scope. This indicates that you declare a class as private but it is still extensible, which is not a good idea.

Avoiding Writing Privileged Code The damage caused by privileged code is higher as compared to non-privileged code because code without signature has fewer privileges. However, there are situations where you would require signed code to perform secret operations. But their usage in Java program should be limited.

Avoiding the Cloneable Interface The object-cloning mechanism of Java is a loophole in the security implementation because an attacker can create new class instances without invoking the constructors. The attacker creates copies of an object instance and uses these for malicious purposes. Even if you do not define the class as cloneable, an attacker can create a subclass from your class and implement the cloneable interface to this subclass. Therefore, an attacker redefines the clone method of your class. To avoid this you can define the following method in all your classes: public final void clone() throws java.lang.CloneNotSupportedException{ throw new java.lang.CloneNotSupportedException(); }

The preceding code statement declares the clone() method as final so that an attacker cannot subclass this method. The preceding method throws an exception to avoid cloning.

Avoiding Storing Secrets in Your Code You should not store sensitive information such as passwords or cryptographic keys in your Java code. If you store sensitive information in your code, users can access that

385

386

Part III

APPENDIXES

data if they run your Java code. If you still want to store secret information in your Java code you can use code obfuscation. However, this method is also not foolproof. Therefore, think twice before storing secrets in your Java code.

Avoiding Comparing Classes by Name A JVM can have multiple classes with similar names. Therefore, when comparing classes by name, you might be unknowingly comparing a different class. It is a good practice to compare objects of the given classes directly. Refer the following code statement for the same: if(x.getClass() == y.getClass()){ System.out.println(“Objects belong to the same class”); } else{ System.out.println(“Objects belong to different classes”); }

By using class names, your code is more susceptible to mix-and-match attacks. These attacks are discussed in the next section. You cannot avoid these attacks at your end. But, you can improve the situation by avoiding class comparisons by name.

Avoiding Mix-and-Match Attacks In mix-and-match attacks, an attacker creates a new class or library linking your signed classes with malicious classes or linking those classes that you never wanted to link. Therefore, it is a good practice to place all code in a JAR file and then sign it. You can also examine other classes to check signatures. However, you cannot avoid these attacks completely. There can also be inter-version mix-and-match attacks in which a different version of a particular class is linked with another version of a different class. You can avoid this by placing the version stamp of the class in a final variable and compare this variable with the version stamps of other classes. However, remember that the variable should be declared as final. The rules or best practices discussed in the preceding sections cannot avoid all security risks for your Java code. But they can minimize them considerably. These are simple issues that are often ignored by a Web developer but are very important for minimizing security risks. You should think logically before implementing any method or class declaration.

Appendix B FAQs

Q. Which of the two, Netscape Navigator or Microsoft Internet Explorer, is more secure? A. The latest version of both the browsers, namely, Internet Explorer 6.0 and Netscape Navigator 6.2, confirm to similar security standards. Q. Can an applet on the Internet start a network connection with another computer? A. Applets can start network connections only with the computer from where the class files were downloaded. This computer is either the one from where the applet was downloaded or the host defined in the codebase attribute of the <APPLET> tag. If an applet tries to establish a connection with any computer other than the two specified here, a security exception is thrown. Q. How does an applet start a connection with its originating host? A. You must specify the same URL name that was used for downloading the applet. If you use the IP address of the host or a short URL name, the applet is unable to start a connection with its host. Q. What effect does the following statement have on the Java 2 security model? Code written in other programming languages can also be compiled to bytecode. A. The class-file verifier is not dependent only on the javac compiler for bytecodes. Bytecode originating from other sources can also pass through various passes of the verifier. For example, the verifier also verifies bytecodes generated from other compilers or bytecodes generated by using other programming languages. Once bytecodes pass the verification phase, they can be trusted to run on any JVM. However, it is not easy for malicious bytecodes downloaded from the Internet to spoof the class-file verifier. The bytecodes are checked for signatures, format, and typing before passing the verifier. Q. Can an applet write to a file? A. By default, applets downloaded in a browser do not have access to the local file system. Therefore, an applet cannot write to a file. The appletviewer permits only those applets that are specified in the access control list to write to a file. By default, the access control list providing permissions to write to a file is empty. You can specify the file where the applet would write in the acl.write property, as shown here: acl.write=/home/MyDir/MyFile

You should provide only trusted applets the permission to write to files. You cannot limit the disk space, which an applet would use to perform the write operation. Therefore, much thought needs to go into the decision of allowing applets to write to the local file system.

FAQs

Appendix B

Q. Can an applet read system properties that it isn’t allowed to read by default? A. An applet cannot read system properties if it isn’t allowed to read by default. For applets to read system properties, add the following statement to the security properties file. property.applet = true

Q. How can you specify a JAR file in the or <EMBED> tag? A. To specify a JAR file in the or <EMBED> tags, specify an ARCHIVE parameter in the or <EMBED> tags. Q. Can the Java Plug-in software support multiple JAR files in the ARCHIVE parameter in the <APPLET> tag? A. Yes, you can place multiple JAR files in the ARCHIVE parameter. The order of the JAR files in the ARCHIVE should be the order of dependency. Assume that you are using the Swing set in Java plug-in software. You set the ARCHIVE parameter as ARCHIVE=”classes.jar,swing.jar,MyClass.jar...”. With the preceding order, the Java plug-in cannot load the applet. This is because first classes.jar is loaded and when the Java plug-in tries to initialize the applet, swing.jar is not yet available. Because swing.jar is needed by all the classes, it should be the first member of the list. Q. Is it true that the Java plug-in replaces the runtime of Internet Explorer or Netscape with Sun’s JRE? A. No, the Java plug-in does not replace the runtime of Internet Explorer or Netscape with Sun’s JRE. It only specifies that Web developers or users can use Sun’s JRE instead of the respective browser’s JVM. Q. Explain the different templates supported by the Java plug-in HTML Converter. A. The Java plug-in HTML Converter provides a default template, default.tpl. The page converted by using this template can be used in Netscape and Internet Explorer to use the Java plug-in software in various browser platforms. In addition, there are three supplementary templates. These templates allow Web page authors to target the browsers and platforms used in their environment while modifying the HTML pages by using the Java plug-in HTML Converter. These templates are ieonly.tpl, nsonly.tpl, and extend.tpl. The page converted by ieonly.tpl support the Java plug-in in Internet Explorer only. The page converted by nsonly.tpl can support the Java plug-in in Netscape Navigator only. The page converted by extend.tpl can support the Java plug-in in any browser on any platform.

389

390

Part III

APPENDIXES

Q. What are the various effects of malicious applets on your system? A. Malicious applets can invoke denial-of-service attacks on your system where the CPU and memory resources on your system are consumed. They can trick you and gain access to sensitive system information. They can trick you to specify your username and password. These applets can freeze your browser and consume all important system resources. This can affect the remaining programs running on your system. They can invoke misleading dialog boxes or prompts on your system. Therefore, the browser and user must specify resource limits on downloaded applets. The security policy specifies that applets cannot access threads outside their own thread group. Therefore, these applets cannot affect the execution of other applets. You can save your system by killing the current applet thread on the browser. Q. Describe the security offered by SSL encryption. A. SSL uses public key encryption to exchange a session key between the client and server. This key is, in turn, used to encrypt the HTTP transaction. To implement high levels of security, each transaction uses a different session key. This indicates that if a hacker manages to decrypt a transaction, it does not necessarily mean that the hacker has deciphered the server’s secret key. In Netscape, you can identify the type of encryption used for a particular document by looking at the document information screen, which can be accessed from the File menu. In Netscape, there is a little key in the lower-left corner of the window indicating this information. If it is a solid key with three teeth, it indicates 128-bit encryption. A solid key with two teeth indicates 40-bit encryption. A broken key means no encryption. Even if your browser supports 128-bit encryption, it can use 40-bit encryption while communicating with older Netscape servers or Netscape servers outside the U.S. and Canada. In Microsoft Internet Explorer, a solid padlock will appear on the bottom right of the screen when encryption is being used. You can determine whether 40-bit or 128-bit encryption is being used by accessing the document information page. You can access this page by using the File, Properties menu. The page indicates whether weak or strong encryption is being used.

Appendix C In the Wings

n this book, you learned all the components of Java 2 security model. This model is more complex and comprehensive as compared to the sandbox model in earlier versions. In this model, the Sun technical team provides mobile code security and tools for building secure applications. However, there are still a number of challenges that remain unresolved in this version release and can act as a future direction for Java security. In this appendix, I’ll discuss the future of Java security.

I

The Future of Java Security Although the Java 2 security model is comprehensive, it still needs to be improved to avoid implementation errors that can be exploited by malicious applets. It is not a trivial task of creating secure Java systems. Java does provide tools that aid in building a secure system. However, you cannot guarantee its 100 percent success. Java has considerably improved its security implementation by adding new features. However, more security threats arise with every new implementation. When new features are added, errors can be introduced at the design stage or the implementation phase. A security bug could have originated from a design stage problem. Therefore for proper usage of complex technologies it is very important for you to think, implement, and manage these technologies. You should look out for new security threats with every emerging technology. The future Java security model will include an extended Java sandbox model and a protected domains model. The extended Java sandbox model implements applet signing by using the following major steps: ◆

Compiles the applet

◆

Creates a JAR file containing all class files

◆

Generates keys

◆

Signs the JAR file by using these keys

◆

Exports the digital certificate

◆

Imports the certificate as a trusted certificate

◆

Creates the policy file containing the permissions

◆

Runs the applet

The protected domains model identifies the following major steps: ◆

Creates permissions for valuable resource access

◆

Accesses a network service

IN THE WINGS

Appendix C

◆

Controls the network resource by setting the security policy

◆

Provides the default setting by using the extended Java sandbox model

I’ll discuss protected domains in the subsequent section.

The Java Protected Domains The Java protected domain is an important element in the evolving Java security model. This security component contains a set of objects identified by a specified principal. A principal is any entity that is authenticated and then authorized for valuable resource access. The protection domains are unique with respect to each other. Only trusted system code is allowed access to interact among different domains. Code can also interact with domains if the associated permission is specified in the system policy. You can compare two applets interacting with different parts of the same file system, but they cannot access each other because one is protected from another by their respective protection domains. There can be two types of protection domains, system and application. All system resources—such as keyboard, CPU, memory, and files—are accessible through their own system domains. For a better security implementation, JVM can create objects of different system domains for a particular system resource. Therefore, if there were an implementation error, its scope would be limited to the particular system domain and not the entire system. The protected domains can also set internal restrictions for their components. A given application can access multiple protected domains. JVM ensures that the application accesses the system resources based on the restrictions placed on it. For example, an application cannot access sensitive data, such as cryptographic keys. However, a trusted system utility can perform a similar operation. Let’s discuss some features that are under construction.

Secure Communication Networked systems are vulnerable to the man-in-the-middle attacks. This attack is initiated when a client contacts a server on the network and requests for some operations. The attacker, in this case, is the man in the middle who is keeping an account of this request and is waiting for the server to respond. The attacker reads the response and sends a bogus reply to the client. Sun’s Simple Key Management Internet Protocol (SKIP) technology allows the client and the server to agree on a common encryption method. This ensures safe communication of secure data.

393

394

Part III

APPENDIXES

Java Encryption Extension ( JEE) is a plug-in module that applies advanced encryption technologies to Java programs. Moreover, the plug-in is implementation- and algorithm-independent. This allows developers to choose from thirdparty encryption schemes.

Table-based Structure Flexible security policies are present only at the developer’s end. However, organizations can take advantage of the flexible and fine-grained security policies by purchasing and extending the security classes. Future Java versions would provide a table-based interface to establish such policies.

Auditing Auditing is crucial in a security scenario where you can keep a record of everything that happens on your system. If an error occurs, the audit log helps system administrators determine the reason for the error. Efforts are still underway for this future direction. The end result would be a set of auditing features provided as a part of the end-deliverable by all vendors.

Domain Identification A problem that can be foreseen in the protected domains model is authentication performed across computers. This would pose a problem for code running on a remote machine to access resources on a local computer. Even if the domain provided access to the resources, the local machine would consider this remote code as untrusted. This can be overcome by assigning IDs and allowing the local machine to authenticate the remote machine. Finally, the certificate usage requires custom development. Java in the future would provide APIs for uniform access to certificate code such as X.509v3. Java would also provide an online Certificate Authority server. These evolutionary structures can further strengthen the security model in Java.

Index A

AppletViewer, security manager and, 52

access, limiting, 384

application class path, 46

access control

application domains, 44

fine-grained control specifications, 40

application-level firewalls, 342

packages, 180

asymmetric key algorithms, 300–302

resources, 48

attributes_count item, class files, 73

AccessController class, 146–147

authentication

checkPermission( ) method, 147–148

cryptography and, 298

doPrivileged( ), 148–149

JAAS, 325

getContext( ) method, 150

CallbackHandler interface, 328–330

privileged code, writing, 150–154

LoginContext, 326 LoginModuleInterface, 327

access_flags item, class files, 72 add( ) method, 84–85

authorization, JAAS, 330–335

Advanced panel, Java plug-in control panel, 252–253

AuthPermission class, JAAS, 333–334

AlgorithmParameters class, 195, 303

B

AlgorithmParameterSpec interface, 41–42

Base 64 encoding, 261

algorithms, JCA, 302–303

Basic panel, Java plug-in control panel, 252

aliases( ) method, 192

BasicPermission class, 161–167

AllPermission class, 52

best practices

applet class loaders, 95–96 namespaces and, 96

access, limiting, 384 classes, final, 385

applet hunters, 15

Cloneable interfaces, 385

<APPLET> tag, 239–240

comparing classes by name, 386

applets

methods, final, 385

downloading, remote servers, 346–347

mix-and match attacks, 386

Java plug-ins and, 247–251

privileged code, 385

security, 18–21

secrets in code, 385–386

security policies, 18–19

static variables, 384

signing, 19–21

396

Index

binary text, Base 64 encoding and, 261 branching instructions, 86 browsers

CAs (Certification Authority) certificates, 185–186, 202 digital certificates, 302

Java plug-in and, 236

CBC (Cipher Block Chaining) mode, 308

SSL support, 359

Certificate interface, java.security package, 41–42

built-in permissions

Certificates KeyStore file, 185–186

java.io.AWTPermission class, 160

CFB (Cipher Feedback) mode, 308

java.io.FilePermission class, 156

check keyword, 65

java.io.SerializablePermission class, 160

check methods

java.lang.reflect.reflectPermission class, 160

class access checks, 126–127

java.lang.RuntimePermission class, 157–158

file system checks, 125–126

java.net.NetPermission class, 159

JVM control, 128–129

java.net.SocketPermission class, 156

network operations, 124–125

java.security.AllPermission class, 155–156

operating system checks, 127–128

java.security.BasicPermission class, 157

package checks, 126–127

java.security.Permission class, 155

thread checks, 126

java.security.SecurityPermission class, 158–159

checkAccept( ) method, 124–125

java.security.UnresolvedPermission class, 157

checkAccess( ) method, 136–137

java.util.PropertyPermission class, 159

checkAwtEventQueueAccess( ) method, 129

bulk encryption, 29

checkConnect( ) method, 124–125

bytecode, 5

checkCreatedClassLoader( ) method, 129

branching instructions, 86

checkDelete( ) method, 125

bytecode check, class file verifier, 113–114

checkExec( ) method, 127–128

illegal instructions, class file verifer and, 111

checkExit( ) method, 128–129

integers, 83

checkLink( ) method, 128

overview, 82–87

checkListen( ) method, 125

types, 84–85

checkMemberAccess( ) method, 127

prefixes, 86

checkMulticast( ) method, 125

bytecode hosting, 81

checkPackageAccess( ) method, 126–127, 180

bytecode verifier, 113–114

checkPackageDefinition( ) method, 127, 180–181

C

checkPermission( ) method, 48 AccessController class, 146–154, 147–148

cacerts file, 185–186

checkPrintJobAccess( ) method, 128

Cache panel, Java plug-in control panel, 253–254

checkPropertiesAccess( ) method, 129

CallbackHandler interface, JAAS, 338–330

Index

checkPropertyAccess( ) method, 129

user-defined class loaders, 101–110

checkRead( ) method, 125

Java 1.1, 102–107

checkSetFactory( ) method, 125

Java 1.2, 108–110

checkSystemClipboardAccess( ) method, 128 checkWrite( ) method, 65, 126 Cipher class, 309–310

class-loading mechanism, 98–99 parent-delegation model, 99–101 class paths, 44

cipher text, 28

application class path, 46

CipherInputStream class, 308–309

system class path, 46–47

CipherOutputStream class, 308–309

Class structure, constant pool, 74

ciphers, SSL and, 357

classes, 44–47

cipher suites, 357 class file verifier, 10–11, 61–62

access checks, SecurityManager class, 126–127 AccessController, 146–154

bytecode check, 113–114

AlgorithmParameters, 195, 303

internal structure checks for class files, 111

AllPermission, 52

semantic checks, 112–113

Cipher, 309–310

symbolic references, 115–117

CipherInputStream class, 308–309

class files

CipherOutputStream, 308–309

format, 71–73

ClassLoader, 47

items, 71

CodeSource, 193–194

loaded, class file verifier and, 61–62

comparing by name, 386

structures, 71

DigestInputStream, 269–271

constant pool, 73–74 class loader objects, 95

DigestOutputStream, 271–273 digital signatures, 281–292

applet class loaders, 95–96

engine classes, JCA, 302–303

types, 95–96

extension classes, 45

class loaders, 9, 47–48, 94

FilePermission, 49

architecture, 94–98

final, 385

defining class loader, 100

GuardedObject, 186–187

hierarchies, 97–98

java.security.CodeSource, 43

initiating class loader, 100

javax.crypto.KeyAgreement, 310–311

java.app.class.path property and, 96

javax.crypto.KeyGenerator, 311

JVM, 59–61

javax.crypto.SealedObject, 311–312

namespaces and, 96–97

KeyPairGenerator, 303

primordial class loader, 95

KeyStore, 303

properties, 95

LoginContext, 326

URL class loaders, 96

Mac, 277–280

397

398

Index

classes (continued) MacSpi, 276–277

CodeSource class, 193–194 commands

message digests, 261–275

jar, 213–216

MessageDigest, 263–266, 303

keytool, 202–204

MessageDigestSpi, 261–262

-certreq option, 205–206

objects and, 6

-delete option, 206

Permission classes, 48–50

-export option, 206

Policy, 194–195

-genkey option, 206–207

ProtectionDomain, 194

-help option, 207

Provider, 187–189

-identitydb, 207–208

SecureClassLoader, 9, 47–48

-import option, 208–209

SecurePasswordManager, 135

-keyclone option, 209–210

SecureRandom, 303

-keypasswd option, 210

Security, 189–191

-keystore option, 205

SecurityManager, 47, 122–130

-list option, 210

Signature, 193, 284–288, 303

-printcert option, 211

SignatureSpi, 281–284

-selfcert option, 211

SignedObject, 192–193

-storepass option, 205

SocketPermission, 49

-storepasswd option, 211

Subject, 323–325

-storetype option, 205

trusted, 59–60

-v option, 204

untrusted, 59–60 ClassFile structure, 71 ClassLoader class, 47 ClassLoader object, 9 className string, class-loading mechanism, 98 CLASSPATH environment variable, 45 clear text, 28 client sockets, SSL, 370–372 clone( ) method, 263, 266, 277 Cloneable interface, 385 code. See source code code obfuscation, 80–81 code source, grant entries, 49 CodeBase clause, 44 codeBase entry, security policy file, 183–184

compiling, 70 constant pool, class file, 73–74 Class structure, 74 Double type, 76 Fieldref constant type, 74–75 Float item, 76 Integer item, 76 InterfaceMethodref constant type, 74–75 Long type, 76 Methodref constant type, 74–75 NameAndType structure, 77 String type, 75 Utf8 type, 77–78 constant_pool table, class files, 71–72

Index

control panel, Java plug-in, 251

HoseMocha and, 81

Advanced panel, 252–253

salting code and, 81–82

Basic panel, 252

threats to, 78–80

Cache panel, 253–254 Proxies panel, 253

prevention, 80–82 decryption, cryptography and, 298–299

convertBase64( ) method, 289

DECRYPT_MODE, transformations, 307

createSign( ) method, 289

default system policy file, 50–52

Crema, 80–81

defineClass( ) method, 101

cryptographic engines, 302–303

defining class loader, 100

cryptography, 27–30 bulk encryption, 29

denial of service attacks, security manager and, 131

cipher text, 28

DES (Data Encryption Standard), 299–300

clear text, 28

development environment, overview, 5–8

cryptographic architecture, 28

Diffie-Hellman keys, javax.crypto.interfaces package, 307

decryption and, 298–299 encryption and, 298–299 hashing, 29 need for, 298–299 public key encryption, 29–30 tools, 29–30 CSPs (Cryptographic Service Providers), 261, 303–305

digest( ) method, 265 digest streams, 273–275 DigestInputStream class, 269–271 DigestOutputStream class, 271–273 digital certificates, 302 digital signatures, 281 classes, SignatureSpi class, 281–284

CSRs (certificate signing requests), 202

cryptography and, 298–299

customization, 7

interfaces, 281–292

permission types, 161–167

jarsigner tool and, 220

security manager, 135–141

Signature class, 193

cycle stealing, 17 security manager and, 133

doFinal( ) method, 279–280 domains, protection domains, 43, 44 doPrivileged( ) method, AccessController class, 148–149

D

Double type, constant pool, 76

data areas, JVM, 58

download extensions, 45

data flow analyzers, bytecode verifier, 116–117

downloading

decompilers benefits of decompilation, 79–80 Crema and, 80

applets, remote servers, 346–347 Java plug-in, 237–238 DSA (Digital Signature Algorithm), 284, 301

399

400

Index

.DSA file extension, 221

extensions

dynamic linking, 5–6

download extensions, 45 installed extensions, 45 extensions mechanism, 45

E e-mail, forging, security manager and, 133–135 ECB (Electronic Codebook) mode, 308

F

<EMBED> tag, 239–240

FAQs, 388–390

encryption

Fieldref constant type, constant pool, 74–75

bulk encryption, 29

fields_count item, class files, 72

cryptography and, 298–299 public key encryption, 29–30

file system checks, SecurityManager class, 125–126

rules for, 30

FilePermission class, 49

ENCRYPT_MODE, transformations, 307

files. See class file verifier

engine classes, JCA, 28, 302–303

findLoadedClass( ) method, 105

engineDigest( ) method, 262–263

findSystemClass( ) method, 102, 106

engineDoFinal( ) method, 276–277

firewalls, 342–343

engineGetDigestLength( ) method, 262

applet downloading, remote servers, 346–347

engineGetMacLength( ) method, 276

application-filtering, 342

engineGetParameter( ) method, 284

network connections and, 347–351

engineInit( ) method, 276

packet-filtering, 342

engineInitSign( ) method, 282

program interaction and, 343–346

engineInitVerify( ) method, 282

proxy servers and, 344–345

engineReset( ) method, 263, 277

SOCKS protocol, 345–346

engineSetParameter( ) method, 283–284

Float item, constant pool, 76

engineSign( ) method, 283

forging e-mail, security manager and, 133–135

engineUpdate( ) method, 262, 276, 282–283 engineVerify( ) method, 283

G

environment variables, CLASSPATH, 45

garbage collection, JVM, 62

environments

generatePrivate( ) method, 191

development environment, overview, 5–8

generatePublic( ) method, 191

execution environment, 8–11

getAlgorithm( ) method, 266, 277, 288

execution environment, 8–11

getCipherSuite( ) method, 375

expansion, property expansion, policy files, 177–178

getCodeSource( ) method, 194

extension classes, 45

getContext( ) method, AccessController class, 150

Index

getCreationTime( ) method, 373

HoseMocha, 81

getDigestLength( ) method, 266 getID( ) method, 372

HTML code, modifying for Java plug-in, 239–245

getInstance( ) method, 188, 264, 278, 285–286

HTML Converter, 245–246

getLastAccessedTime( ) method, 373 getLocalCertificates( ) method, 374

I

getMacLength( ) method, 278–279

implies( ) method, Permission class, 160–161

getMessageDigest( ) method, 270, 271

init( ) method, 279

getParameter( ) method, 288

initiating class loader, 100

getPeerCertificateChain( ) method, 375

initSign( ) method, 286

getPeerCertificates( ) method, 374–375

initVerify( ) method, 286

getPeerHost( ) method, 375

installation

getProperty( ) method, 191 getProtocol( ) method, 375–376 getProvider( ) method, 190–191, 264, 278, 286, 304 getProviders( ) method, 190–191, 304 getSessionContext( ) method, 372–373 getValue( ) method, 374 getValueNames( ) method, 374 grant directives, 48–50 grant entries policy file, 43 code source, 49 permission list, 49–50 policy files, 182 Guard interface, 186–187 GuardedObject class, 186–187

Java plug-in, 237–239 providers, 188–189 security manager, 130 installed extensions, 45 Integer item, constant pool, 76 integers, bytecode, 83 InterfaceMethodref constant type, constant pool, 74–75 interfaces AlgorithmParameterSpec, 41–42 digital signatures, 281–292 Guard, 186–187 Java, 11–13 KeySpec, 41–42 message digests, 261–275 Principal, 194 interfaces_count item, class files, 72

H hash values, 260. See also message digests

internal structure checks for class files, class file verifier and, 111

hierarchies, class loaders, 97–98

Internet Explorer, Java plug-in and, 241–242, 242–243

history of Java security

introspection, 7

hashing, cryptography, 29

sandbox model, 37–38

invalidate( ) method, 373

trusted code model, 38–39

isEqual( ) method, 266

401

402

Index

J

-sectionsonly option, 225

JAAS ( Java Authentication and Authorization Services), 322

-sigfile option, 224 -signedjar option, 224

APIs, 323–335

-storepass option, 223

authentication, 325


CallbackHandler interface, 328–330

-verbose option, 225

LoginContext, 326

-verify option, 224–225

LoginModuleInterface, 327

options, 222–223

authorization, 330–335 AuthPermission class, 333–334

use, 225–229 Java

java.security file settings, 335–336

overview, 5–13

Policy class, 331

security and, 13–15

PolicyFile class, 331–333

Java 1.1, user-defined class loaders, 102–107

Private CredentialPermission class, 334–335

Java 1.2, user-defined class loaders, 108–110

jar command, 213–216 JAR files, 8 contents

Java 2 applet security, 18–21 application security, 27

extracting, 218

permissions, built-in, 154–160

viewing, 216–217

security APIs, 186

creating, 20 jar tool and, 213–216

security model, 40–42 Java 2 SDK, security tools, 7–8

installed extensions, 45

Java beans, 6–7, 13

javakey tool, 39

Java plug-in

signed, contents, 221–222

applets and, 247–251

signing, 20–21

control panel, 251

signing applets and, 20

Advanced panel, 252–253

software, running, 219–220

Basic panel, 252

updating, 218–219

Cache panel, 253–254

jar tool, 7–8, 42, 213

Proxies panel, 253

JAR files, creating, 213–216

features, 236–237

remote codes and, 38–39

HTML code modification, 239–240

jarsigner tool, 7–8, 42, 220–221 -certs option, 225

Internet Explorer, 241–242, 242–243 Netscape Navigator, 240–241, 242–243

-internalsf option, 225

HTML Converter and, 245–246

-keypass option, 223–224

installation, 237–239


security, 246–247

Index

java.app.class.path property, class loaders and, 96

java.security.UnresolvedPermission class, 157

java.class.path property, 46

java.util.PropertyPermission class, 159

java.io.AWTPermission class, 160

javax.crypto package, 305–306

java.io.FilePermission class, 156

javax.crypto.Cipher class, 307–308

java.io.SerializablePermission class, 160

javax.crypto.KeyAgreement class, 310–311

javakey tool, JAR files and, 39

javax.crypto.KeyGenerator class, 311

java.lang.ClassLoader class, 9

javax.crypto.SealedObject class, 311–312

java.lang.reflect.reflectPermission class, 160

javax.net package, 360

java.lang.RuntimePermission class, 157–158

javax.net.ssl package, 360–361

java.lang.SecurityException, 11

javax.security.cert package, 362

java.net.NetPermission class, 159

JCA ( Java Cryptography Architecture), 302

java.net.SocketPermission class, 156

classes, 303

javap assembler, 82

cryptographic engines, 302–303

java.policy property, 19

CSPs, 303–305

java.security package, 39

engine classes, 28

AlgorithmParameters class, 195 CodeSource class, 193–194

JCE ( Java Cryptography Extension), 28, 305–307

Guard interface, 186–187

algorithm independence, 312–313

GuardedObject class, 186–187

javax.crypto.Cipher class, 307–308

keystore management, 191–192

provider independence, 312–313

Policy class, 194–195

providers, creating, 313–316

Principal interface, 194

secret keys, 312

ProtectionDomain class, 194

subjects

Provider class, 187–189

attributes, 324–325

Security class, 189–191

creating, 324

SignedObject class, 192–193

JDBC ( Java Database Connectivity), 12–13

java.security.acl package, 39, 196

jdk1.1, 17

java.security.AllPermission class, 155–156

JIT ( Just In Time) compilation, 8

java.security.BasicPermission class, 157

JVM and, 63–64

java.security.cert package, 41–42, 196

jks ( Java Keystore) keystore type property, 179

java.security.CodeSource class, 43

JRE ( Java Runtime Environment), 5

java.security.interfaces package, 39, 196

JSSE ( Java Secure Socket Extension), 359–362

java.security.Permission class, 155

providers, 363

java.security.SecurityPermission class, 158–159

SSL and, 362–377

java.security.spec package, 41–42, 195

JVM control, SecurityManager class, 128–129

403

404

Index

JVM ( Java Virtual Machine), 5

-export option, 206

architecture, class loader, 59–61

-genkey option, 206–207

execution and, 8–11

-help option, 207

execution engine, 64

-identitydb, 207–208

garbage collection, 62

-import option, 208–209

JIT compilers and, 63–64

-keyclone option, 209–210

JVM heap, 58, 62

-keypasswd option, 210

method area, 62–63


native method stacks, 63

-list option, 210

safety features, 58–59

-printcert option, 211


-selfcert option, 211 -storepass option, 205 -storepasswd option, 211–212

K


key agreements, 310–311

-v option, 204–205

key algorithms

key pair generation, 212–213

asymmetric, 300–302

keystore creation, 212–213

symmetric, 299–300

syntax, 203–204

Key class, JCA, 303 key pairs, generation, keytool command, 212–213 KeyAgreement instance, 311

keytool tool, 7–8, 42 keywords check, 65

keyalg keyword, 207

keyalg, 207

KeyPairGenerator class, 303

permission, 49–50

KeySpec interface, 41–42

private, 6

KeyStore class, 303

protected, 6

keystore type, policy files, 179

public, 6

keystores, 8 creation, keytool command, 212–213 entries, 202

L

JAR files, 20–21

ldc instruction, 83

java.security package, 191–192

limitations of Java security, 16–17

Policy tool, 24–26

limiting access, 384

security policy files, 181–182

loadClass( ) method, 98

keytool command, 202–204

LoginContext class, JAAS, 326

-certreq option, 205–206

LoginModule interface, JAAS, 327

-delete option, 206

Long type, constant pool, 76

Index

M

checkPackageAccess( ), 126–127

Mac( ) constructor, 277

checkPackageDefinition( ), 127

Mac class, 277–280

checkPermission( ), 48

MACs (Message Authentication Codes), 275–280

checkPrintJobAccess( ), 128

MacSpi class, 276–277

checkPropertyAccess( ), 129

main( ) method, security manager, custom, 138

checkRead( ), 125

MD5 (Message Digest 5), 260

checkSetFactory( ), 125

message digests, 260. See also hash values

checkSystemClipboardAccess( ), 128

checkPropertiesAccess( ), 129

Base 64 encoding, 261

checkWrite( ), 65, 126

classes, 261–275

clone( ), 263, 266

computing, 267–269

convertBase64( ), 289

interfaces, 261–275

createSign( ), 289

MACs, 275–280

defineClass( ), 101

MessageDigest class, 263–266, 303 JCA, 303

digest( ), 265 doFinal( ), 279–280

MessageDigestSpi class, 261–262

engineDigest( ), 262–263

method areas, JVM, 58, 62–63

engineDoFinal( ), 276–277

Methodref constant type, constant pool, 74–75 methods AccessController class, 147–150 add( ), 84–85 aliases( ), 192 checkAccept( ), 124–125 checkAccess( ), 136–137 checkAwtEventQueueAccess( ), 129 checkConnect( ), 124–125 checkCreatedClassLoader( ), 129 checkDelete( ), 125 checkExec( ), 127–128 checkExit( ), 128–129 checkLink( ), 128 checkListen( ), 125 checkMemberAccess( ), 127 checkMulticast( ), 125

engineGetDigestLength( ), 262 engineGetMacLength( ), 276 engineGetParameter( ), 284 engineInit( ), 276 engineInitSign( ), 282 engineInitVerify( ), 282 engineReset( ), 263, 277 engineSetParameter( ), 283–284 engineSign( ), 283 engineUpdate( ), 262, 276, 282–283 engineVerify( ), 283 final, 385 findLoadedClass( ), 105 findSystemClass( ), 102, 106 generatePrivate( ), 191 generatePublic( ), 191

405

406

Index

methods (continued)

removeValue( ), 374

getAlgorithm( ), 266, 277, 288

reset( ), 266, 280

getCipherSuite( ), 375

resolveClass( ), 102

getCodeSource( ), 194

setMessageDigest( ), 270, 272

getCreationTime( ), 373

setParameter( ), 288

getDigestLength( ), 266

setProperty( ), 191

getID( ), 372

sign( ), 286–287

getInstance( ), 264, 278, 285–286

super( ), 314

getLastAccessedTime( ), 373

toString( ), 265, 271, 272–273

getLocalCertificates( ), 374

update( ), 264–265, 279, 287–288

getMacLength( ), 278–279

user-defined class loaders, 101

getMessageDigest( ), 270, 271

verify( ), 287

getParameter( ), 288

verifyAccess( ), 136

getPeerCertificate( ), 374–375

write( ), 272

getPeerCertificateChain( ), 375

methods_count item, class files, 72

getPeerHost( ), 375

mix-and-match attacks, 386

getProperty( ), 191 getProtocol( ), 375–376 getProvider( ), 190–191, 264, 278, 286, 304 getProviders( ), 190–191, 304

N NameAndType structure, constant pool, 77 namespaces

getSessionContext( ), 372–373

applet class loaders and, 96

getValue( ), 374 getValueNames( ), 374 init( ), 279

class loaders and, 96–97 native methods, stacks, JVM, 63

initSign( ), 286

Netscape Navigator, Java plug-in and, 240–241, 242–243

initVerify( ), 286

network connections, firewalls and, 347–351

invalidate( ), 373

network operations, check methods, 124–125

isEqual( ), 266

niitpolicy file, 178–179

loadClass( ), 98

non-repudiation, cryptography and, 298

native, JVM, 63 on( ), 270–271, 272 overriding, 137 putValue( ), 373 read( ), 270 refresh( ), 43

O obfuscation, 80–81 object-oriented langauges, 5 tag, 239–240

Index

objects

Permissions dialog box, Policy tool, 22

classes and, 6

persistence, 7

ClassLoader, 9 OFB (Output Feedback) mode, 308

PKCS (Public-Key Cryptography Standards), 205–206

on( ) method, 270–271, 272

policies, user-defined security policies, 53

opcodes, 113


bytecode verifier checks and, 113–114

JAAS, 331

operand stack, JVM, 113

Policy Entry window, Policy tool, 22

operating system checks, SecurityManager class, 127–128

policy files

oversized windows, security manager and, 133

additional, specifying, 178–179 default system policy file, 50–52 grant directives, 48–50

P

grant entries, 43, 182

package checks, SecurityManager class, 126–127

keystore type, 179

package definition, 180–181

niitpolicy file, 178–179

packages, 6

permissions, 40

access, checking, 180

properties, expansion, 177–178

certificate handling, 41–42

security policy file, 181–185

scope, 384

URLs, 177

packet-filtering firewalls, 342

policy identity scope, 179

padding, 308

policy providers, security properties file, 176–177

parameters, illegal, class file verifier and, 111

Policy tool, 7–8, 21–26, 42

parent-delegation model, class-loader mechanism, 99–101

keystores, 24–26 permissions file, 42–43

Permission class, implies( ) method, 160–161

PolicyFile class, JAAS, 331–333

Permission classes, 48–50

policy.java property, 18

permission entries, security policy file, 184–185

primoridal class loader, 95

permission keyword, 49–50

Principal interface, 194

permission list, grant entries, 49–50

private key, digital signatures, 281

Permission object, 48

private keyword, 6

permissions built-in, Java 2, 154–160

PrivateCredentialPermission class, JAAS, 334–335

custom types, 161–167

privileged code

grant entries, 43

AccessController class, 150–154

policy file, 43

best practices, 385

policy files, 40

program interaction through firewalls, 343–346

407

408

Index

properties

resolveClass( ) method, 102

class loaders, 95

resources, access control, 48

policy files, expansion, 177–178

reverse engineering, 78–80

security properties file, 172–175

RMI class loaders, 96

policy providers, 176–177

RMI (Remote Method Invocation), 12, 13

security providers, 175–176

RSA (Rivest Shamir Adleman), 301

protected keyword, 6 protection domains, 43, 44 application, 44 system, 44 ProtectionDomain class, 194 Provider class, 176, 187–189 JCA, 303–304 provider installation, 188–189 providers creating, JCE and, 313–316 installing, 188–189 JSSE, 363 SunJCE, 305 Proxies panel, Java plug-in control panel, 253 proxy servers, firewalls and, 344–345 public key algorithms, 300–302 public key encryption, 29–30 digital signatures, 281 public keyword, 6 putValue( ) method, 373

S salting code, 81–82 sandbox security model, 37–38 scope packages, 384 policy identity scope, 179 system identity scope, 179–180 SealedObject instance, 311–312 SecretKey interface, 312 SecretKeySpec class, 312 secrets in code, 385–386 secure class loaders, 96 SecureClassLoader class, 9, 47–48 SecurePasswordManager class, 135 SecureRandom class, 303 security Java 2 SDK tools, 7–8 Java and, 13–15 Java plug-in, 246–247 limitations, 16–17

R read( ) method, 270 refresh( ) method, 43

need for, 4–5 security APIs, 41–42 java.security package

remote code, signed, 38–39

AlgorithmParameters class, 195

remote servers, applet download and, 346–347

CodeSource class, 193–194

removeValue( ) method, 374

Guard interface, 186–187

reset( ) method, 266, 280

GuardedObject class, 186–187

Index

keystore management, 191–192

keystore entries, 181


permission entries, 184–185

ProtectionDomain class, 194

signedBy entry, 183

Provider class, 187–189

security properties file, 172–175

Security class, 189–191

policy providers, 176–177


security providers, 175–176

java.security.acl package, 196

security requirements, 14–15

java.security.cert package, 196

SecurityException, 48

java.security.interfaces package, 196 java.security.spec package, 195 Security class, 189–190

verifyAccess( ) method, 136 SecurityManager class, 47, 122–124 check methods, network operations, 124–125

getProperty( ) method, 191

class access checks, 126–127

getProvider( ) method, 190–191

file system checks, 125–126

getProviders( ) method, 190–191

JVM control, 128–129

JCA, 303

network operation checks, 124–125

setProperty( ) method, 191

operating system checks, 127–128

security features, 15–16

package checks, 126–127

security functions, SecurityManager class, 129–130

security functions, 129–130 thread checks, 126

Security Manager, 11

semantic checks, class file verifier and, 112–113


server sockets, SSL

areas not controlled, 131–133

client authentication, 369–370

customized, writing, 135–141

client requests, 368–369

cycle stealing, 133

server socket factory, 363–367

e-mail, forging, 133–135

setMessageDigest( ) method, 270, 272

flow of operation, 130

setParameter( ) method, 288

installation, 130

setProperty( ) method, 191

JVM, 64–65

SHA-1 (Secure Hash Algorithm1), 260

windows, oversized, 133

sign( ) method, 286–287

security policies applets, 18–19 user-defined, 53 security policy file

Signature( ) constructor, 285 Signature class, 193, 284–288, 303 JCA, 303 signature verification, 289–292

codeBase entry, 183–184

signature-generation algorithms, 28

grant entries, 182

signatures, verification, 289–292

409

410

Index

SignatureSpi class, 281–284

symmetric key algorithms, 299

signed JAR files, contents, 221–222 signed remote code, 38–39

DES, 299–300 syntax

SignedBy clause, 43–44

grant entries, 43

signedBy entry, security policy file, 183

keytool command, 203–204


system class path, 46–47

signing applets, 19–21

system domains, 44

signing JAR files, 20–21

system identity scope, 179–180

SMTP (Simple Mail Transfer Protocol), 133–135

system policy file, default system policy file, 50–52

SocketPermission class, 49 SOCKS protocol, 345–346 software, in JAR files, running, 219–220

T

source code

this_class item, class files, 72

compiling, 70

thread checks, SecurityManager class, 126

secrets in, 385–386

toString( ) method, 265, 271, 272–273

SSL (Secure Socket Layer), 356–357

transformations, 307

browsers and, 359

trusted classes, 59–60

ciphers, 357

trusted code security model, 38–39

client sockets, creating, 370–372

types

JSSE and, 362–377

bytecode, 84–85

server sockets, creating, 363–370

prefixes, 86

SSL handshake, 357–359

constant pool, 74

SSLSession interface, 372–376 SSLSessionContext interface, 376 String type, constant pool, 75 Subject class, 323–325 subjects, JCE attributes, 324–325 creating, 324 SunJCE provider, 305 super( ) method, 314 super_class item, class files, 72 symbolic reference check, class file verifier, 115–117

U u1 types, class files, 71 u2 types, class files, 71 u4 types, class files, 71 untrusted classes, 59–60 update( ) method, 264–265, 279, 287–288 URL class loaders, 96 URLs (Uniform Resource Locators), policy files, 177

Index

user-defined class loaders, 101–110 creating Java 1.1, 102–107 Java 1.2, 108–110 user-defined security policies, 53 Utf8 type, constant pool, 77–78

variables CLASSPATH environment variable, 45 static, best practices, 384 verification. See also class file verifier signatures, 289–292 verify( ) method, 287 verifyAccess( ) method, 136

V VABs (Visual Application Builders), 6 Java beans and, 6–7 values, constant pool, 74

W windows, oversized, security manager and, 133 write( ) method, 272

411

Java Security

Java Security

Java Security

Java Security Solutions

Java Security Handbook

Java Security (Java Series (O'Reilly & Associates).)

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Inside Java 2 Platform Security

Inside Java 2 Platform Security

Java

Java Internationalization (Java Series)

Java

Java, Java, Java, Object-Oriented Problem Solving

Java, Java, Java: Object-Orienting Problem Solving

Java I O (O'Reilly Java)

Expert Oracle and Java Security: Programming Secure Oracle Database Applications with Java

Expert Oracle and Java Security: Programming Secure Oracle Database Applications with Java

Java Virtual Machine (Java Series)

Security

Security

Security

Security

Security

Security

Security

Security

Security

Security

Java Security

Java Security

Java Security

Java Security Solutions

Java Security Handbook

Java Security (Java Series (O'Reilly & Associates).)

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Embedded Java Security: Security for Mobile Devices

Inside Java 2 Platform Security

Inside Java 2 Platform Security

Java

Java Internationalization (Java Series)

Java

Java, Java, Java, Object-Oriented Problem Solving

Java, Java, Java: Object-Orienting Problem Solving

Java I O (O'Reilly Java)

Expert Oracle and Java Security: Programming Secure Oracle Database Applications with Java

Expert Oracle and Java Security: Programming Secure Oracle Database Applications with Java

Java Virtual Machine (Java Series)

Security

Security

Security

Security

Security

Security

Security

Security

Security

Security

Recommend Documents