Inside Java 2 Platform Security Architecture API

Design and Implementation 2nd Edition Li Gong

pdf download

https://ebookname.com/product/inside-java-2-platform-security-
architecture-api-design-and-implementation-2nd-edition-li-gong/

Get the full ebook with Bonus Features for a Better Reading Experience on ebookname.com
Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Java Data Mining Strategy Standard and Practice A

Practical Guide for architecture design and
implementation 1st Edition Mark F. Hornick

https://ebookname.com/product/java-data-mining-strategy-standard-
and-practice-a-practical-guide-for-architecture-design-and-
implementation-1st-edition-mark-f-hornick/

API Std 1164 SCADA Security First Edition Api

https://ebookname.com/product/api-std-1164-scada-security-first-
edition-api/

Software Architecture Design Patterns in Java 1st

Edition Partha Kuchana

https://ebookname.com/product/software-architecture-design-
patterns-in-java-1st-edition-partha-kuchana-2/

Organizational Behaviour Canadian Edition Mitchell J.

Neubert

https://ebookname.com/product/organizational-behaviour-canadian-
edition-mitchell-j-neubert/
A Revised List of Roman Memorial and Triumphal Arches
Analecta Gorgiana 1st Edition Arthur Frothingham

https://ebookname.com/product/a-revised-list-of-roman-memorial-
and-triumphal-arches-analecta-gorgiana-1st-edition-arthur-
frothingham/

The Stuffed Owl An Anthology of Bad Verse D.B. Wyndham

Lewis

https://ebookname.com/product/the-stuffed-owl-an-anthology-of-
bad-verse-d-b-wyndham-lewis/

Mobile Citizenship Spatial Privilege and the

Transnational Lifestyles of Senior Citizens 1° Edition
Margit Fauser

https://ebookname.com/product/mobile-citizenship-spatial-
privilege-and-the-transnational-lifestyles-of-senior-
citizens-1-edition-margit-fauser/

Introduction to the Mathematics of Medical Imaging 2nd

Edition Charles L. Epstein

https://ebookname.com/product/introduction-to-the-mathematics-of-
medical-imaging-2nd-edition-charles-l-epstein/

Security Awareness Applying Practical Security in Your

World 3rd Edition Mark Ciampa

https://ebookname.com/product/security-awareness-applying-
practical-security-in-your-world-3rd-edition-mark-ciampa/
The Moral Wager Evolution and Contract 1st Edition
Malcolm Murray

https://ebookname.com/product/the-moral-wager-evolution-and-
contract-1st-edition-malcolm-murray/
 Inside Java™ 2 Platform Security:

Architecture, API Design, and

Implementation, Second Edition

By Li Gong, Gary Ellison, Mary Dageforde

Publisher: Addison Wesley

Pub Date: June 06, 2003

ISBN: 0-201-78791-1
Copyright

Many of the designations used by manufacturers and sellers to distinguish their

products are claimed as trademarks. Where those designations appear in this
book, and Addison-Wesley was aware of a trademark claim, the designations
have been printed with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but
make no expressed or implied warranty of any kind and assume no
responsibility for errors or omissions. No liability is assumed for incidental or
consequential damages in connection with or arising out of the use of the
information or programs contained herein.

The publisher offers discounts on this book when ordered in quantity for bulk
purchases and special sales. For more information, please contact:

U.S. Corporate and Government Sales

(800) 382-3419
[email protected]

For sales outside of the U.S., please contact:

International Sales
(317) 581-3793
[email protected]

Visit Addison-Wesley on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data is available.

Copyright © 2003 by Sun Microsystems, Inc.

150 Network Circle, Santa Clara, California 95054, U.S.A.

All rights reserved.

Duke™ designed by Joe Palrang

Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun logo,
the Sun Microsystems Computer Corporation logo, Java, JavaSoft, Java Software,
JavaScript, Java Authentication and Authorization Service, JAAS, Java
Cryptography Extension, JCE, Java GSS-API, Java Secure Socket Extension, JSSE,
Java IDL, Java Plug-in, Java Remote Method Invocation, Java RMI, Java Web Start,
EmbeddedJava, PersonalJava, JVM, JavaOS, J2EE, J2ME, J2SE, JDK, and J2SDK are
trademarks or registered trademarks of Sun Microsystems, Inc. UNIX® is a
registered trademark in the United States and other countries, exclusively
licensed through X/Open Company, Ltd. All other product names mentioned
herein are the trademarks of their respective owners.

Sun Microsystems, Inc. has intellectual property rights relating to technology

described in this publication. In particular, and without limitation, these
intellectual property rights may include one or more of the U.S. patents listed
at http://www.sun.com/patents and one or more additional patents or pending
patent applications in the U.S. and other countries.

THIS PUBLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,

EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NON-INFRINGEMENT.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR

TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE
INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW
EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE
IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE
PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.

All rights reserved. No part of this publication may be reproduced, stored in

a retrieval system, or transmitted, in any form, or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior consent of
the publisher. Printed in the United States of America. Published simultaneously
in Canada.

For information on obtaining permission for use of material from this work,
please submit a written request to:

Pearson Education, Inc.

Rights and Contracts Department
75 Arlington Street, Suite 300
Boston, MA 02116
Fax: (617) 848-7047

Text printed on recycled paper

1 2 3 4 5 6 7 8 9 10—CRS—0706050403

First printing, May 2003

Dedication
To Roger Needham, 1935–2003

My supervisor, mentor, colleague, and friend

—Li Gong

To SAM

—Gary Ellison

To my husband, Tom Wills

—Mary Dageforde
The Java™ Series

Lisa Friendly, Series Editor

Tim Lindholm, Technical Editor

Ken Arnold, Technical Editor of The Jini™ Technology Series

Jim Inscore, Technical Editor of The Java™ Series, Enterprise Edition

http://www.javaseries.com

Eric Armstrong, Stephanie Bodoff, Debbie Carson, Maydene Fisher, Dale Green,
Kim Haase
The Java™ Web Services Tutorial

Ken Arnold, James Gosling, David Holmes

The Java™ Programming Language, Third Edition

Joshua Bloch
Effective Java™ Programming Language Guide

Mary Campione, Kathy Walrath, Alison Huml

The Java™ Tutorial, Third Edition: A Short Course on the Basics

Mary Campione, Kathy Walrath, Alison Huml, Tutorial Team

The Java™ Tutorial Continued: The Rest of the JDK™

Patrick Chan
The Java™ Developers Almanac 1.4, Volume 1

Patrick Chan
The Java™ Developers Almanac 1.4, Volume 2

Patrick Chan, Rosanna Lee

The Java™ Class Libraries, Second Edition, Volume 2: java.applet, java.awt,
java.beans

Patrick Chan, Rosanna Lee, Doug Kramer

The Java™ Class Libraries, Second Edition, Volume 1: java.io, java.lang, java.math,
java.net, java.text, java.util

Patrick Chan, Rosanna Lee, Doug Kramer

The Java™ Class Libraries, Second Edition, Volume 1: Supplement for the Java™ 2
Platform, Standard Edition, v1.2

Kirk Chen, Li Gong

Programming Open Service Gateways with Java™ Embedded Server

Zhiqun Chen
Java Card™ Technology for Smart Cards: Architecture and Programmer's Guide

Maydene Fisher, Jon Ellis, Jonathan Bruce

JDBC™ API Tutorial and Reference, Third Edition

Li Gong, Gary Ellison, Mary Dageforde

Inside Java™ 2 Platform Security, Second Edition: Architecture, API Design, and
Implementation

James Gosling, Bill Joy, Guy Steele, Gilad Bracha

The Java™ Language Specification, Second Edition

Doug Lea
Concurrent Programming in Java™, Second Edition: Design Principles and Patterns

Rosanna Lee, Scott Seligman

JNDI API Tutorial and Reference: Building Directory-Enabled Java™ Applications

Sheng Liang
The Java™ Native Interface: Programmer's Guide and Specification

Tim Lindholm, Frank Yellin

The Java™ Virtual Machine Specification, Second Edition

Roger Riggs, Antero Taivalsaari, Mark VandenBrink

Programming Wireless Devices with the Java™ 2 Platform, Micro Edition

Henry Sowizral, Kevin Rushforth, Michael Deering

The Java 3D™ API Specification, Second Edition

Sun Microsystems, Inc.

Java™ Look and Feel Design Guidelines: Advanced Topics

Kathy Walrath, Mary Campione

The JFC Swing Tutorial: A Guide to Constructing GUIs

Seth White, Maydene Fisher, Rick Cattell, Graham Hamilton, Mark Hapner
JDBC™ API Tutorial and Reference, Second Edition: Universal Data Access for the
Java™ 2 Platform

Steve Wilson, Jeff Kesselman

Java™ Platform Performance: Strategies and Tactics

The Jini™ Technology Series

Eric Freeman, Susanne Hupfer, Ken Arnold

JavaSpaces™ Principles, Patterns, and Practice

The Java™ Series, Enterprise Edition

Stephanie Bodoff, Dale Green, Kim Haase, Eric Jendrock, Monica Pawlan, Beth
Stearns
The J2EE™ Tutorial

Rick Cattell, Jim Inscore, Enterprise Partners

J2EE™ Technology in Practice: Building Business Applications with the Java™ 2
Platform, Enterprise Edition

Mark Hapner, Rich Burridge, Rahul Sharma, Joseph Fialli, Kim Haase
Java™ Message Service API Tutorial and Reference: Messaging for the J2EE™
Platform

Inderjeet Singh, Beth Stearns, Mark Johnson, Enterprise Team

Designing Enterprise Applications with the Java™ 2 Platform, Enterprise Edition

Vlada Matena, Sanjeev Krishnan, Beth Stearns

Applying Enterprise JavaBeans™ 2.1, Second Edition: Component-Based
Development for the J2EE™ Platform

Bill Shannon, Mark Hapner, Vlada Matena, James Davidson, Eduardo Pelegri-
Llopart, Larry Cable, Enterprise Team
Java™ 2 Platform, Enterprise Edition: Platform and Component Specifications

Rahul Sharma, Beth Stearns, Tony Ng

J2EE™ Connector Architecture and Enterprise Application Integration
Preface

Inventing is a combination of brains and materials. The more brains you

use, the less material you need.

—Charles Kettering

The phrases "computer security," "network security," and "information security"

conjure up various notions and precepts to a given audience. Some people tend
to envision technical measures, such as cryptography, as the sole means by
which security is attained. Other people recognize the limitations of various
technical measures and treat them as tools that, when used in combination with
other technical measures, can accomplish the task at hand. The distinction is
subtle but important. The phrase "platform security" reflects a holistic view of
security, suggesting that the foundation is secure and can be relied on as is or
used as a secure subsystem to leverage when building larger systems. Building
a secure platform is a very difficult and exacting task that historically has been
accomplished only when security is a design requirement that is taken into
consideration at the onset. The idea that security can be "bolted on" has proved
frail and wrought with failure modes, which has led to a mulititude of security
breaches.

Java technology is possibly the only general-purpose secure computing platform

to become commercially successful. This would never have happened had the
designers not taken security seriously from the start. The security properties
of Java technology are many, and the Java platform builds on itself to create a
reliable and secure platform. The Java 2 security model would be impossible to
make trustworthy if it were not for the safety net provided by the Java language
itself. The Java language specifies the semantics to ensure type safety and
referential integrity and yet would fail miserably if it were not for the
enforcement and assurances the Java virtual machine provides. Thus, from
these various secure subsystems, we have created a greater whole.

The target audience of this book is varied. We believe this book will be a useful
resource to those seeking a general understanding of the security foundation
the Java 2 security architecture provides and relies on. The book should also
prove particularily useful to software practitioners building enterprise-class
applications that must meet varied security requirements, ranging from
authentication to authorization to information protection. This book provides
insight into some of the design trade-offs we made as we developed the platform
and the lessons we have learned as we continue to evolve and enhance the
platform. We provide guidance to those needing to customize the security model
for their specific purposes. We describe the inflection points we designed into
the platform to accommodate those rare but critical customizations. Most of
the aforementioned topics are targeted to system developers, yet we recognize
that security is not limited to the implementation of an application. Equally
important is the deployment of the application. For deployers, we supply
descriptions ranging from expressing security policy to hardening the
installation of the runtime environment.

This book does not explain to any level of detail the Java programming language.
We recommend the book by Arnold and Gosling [3] as a good starting point. Also,
we do not cover the various security APIs in their entirety, and thus we refer the
reader to the Java 2 SDK documentation.

How This Book Is Organized

The text of this book is organized to cater to its various audiences. The first two
chapters supply background information providing the basis for more specific
topics covered in subsequent chapters. The reader need not be proficient in the
Java language to understand these introductory chapters. Chapters 3 through
6 describe the Java 2 security architecture, starting with general concepts and
ending with comprehensive coverage of security policy enforcement. Chapters
7 through 11 are targeted toward the enterprise application developer, covering
topics ranging from trust establishment to cryptography and network security.
For these chapters, Java language proficiency is assumed. Chapter 12 is directly
targeted toward deployers, who should also read Chapter 8 for additional details
about trust establishment. It is our belief that deployers need not be proficient in
the Java language and that they can ignore the sections of Chapter 8 describing
APIs.
The content of each chapter of this book is as follows:

Chapter 1: A general background on computer, network, and

information security

Chapter 2: A review of the Java security models, starting with the

original sandbox and progressing to the fine-grained access control
model

Chapter 3: An in-depth look at the Java 2 security architecture, which is

policy driven and capable of enforcing fine-grained access controls

Chapter 4: Detailed coverage of class loading, including a description

of the class loader inheritance hierarchy and the runtime delegation
hierarchy

Chapter 5: An explanation of the security classes that supply the

foundation for the enforcement of security policy at runtime

Chapter 6: Thorough coverage of the policy enforcement classes and the

design of the Java 2 security architecture access control algorithm

Chapter 7: An explanation of the customization points provided for

systems programmers who need to enhance the core security
architecture

Chapter 8: An outline of the trust establishment capabilities and

mechanisms supplied by the security architecture

Chapter 9: A presentation of common pitfalls and defensive

programming strategies

Chapter 10: Comprehensive coverage of the cryptography-related APIs

Chapter 11: An operational overview of the APIs used to secure network

protocols, including those for authentication, confidentiality, and
integrity protection
 Chapter 12: A presentation of the deployment options that may be used
to securely deploy the Java runtime and Java technology-based
applications

Chapter 13: A look at the various Java technology platforms and a

glance toward the future of Java security

Acknowledgments
This project began as a casual conversation between Li Gong and me at the 2001
JavaOne conference in San Francisco. Prior to that conversation, Li had
transitioned from the role of chief security architect for the Java 2 security
development project to leading Project JXTA, whereas I had transitioned into
the lead security architect role for the Java 2 development team near the end
of the prior millennium. I mentioned to Li that the security architecture had
evolved to the point that the first edition was no longer current and thus not an
authoritative text.

Nearly two years later, the results of that conversation have come to fruition,
and I can confidently state that we have come a long way to reach our goal of
producing a book that thoroughly and accurately describes the Java 2 security
architecture. This clearly would not have been possible without Li's support, and
I am grateful for having had the opportunity to work with Li in the past and
especially on this project.

This book would probably be stuck in the starting blocks if it were not for the
guidance and gentle nudging of Lisa Friendly, Manager of Software Technical
Publications at Sun Microsystems. Lisa recognized early on that my commitment
to the project was absolute but that my copious free time, which was allotted to
this effort, fell between the hours of 10 P.M. and 2 A.M. Lisa quickly solved this
problem by engaging Mary Dageforde as technical editor. I am forever grateful.
Not only is Mary an excellent technical writer and editor who ended up writing
enough to get coauthor billing, but she can code too! Mary truly made this
project happen with her drive, dedication, and thoroughness. I cannot say
enough about Mary, so I will keep it brief. Thank you, Mary.

Tim Lindholm was also an early inspiration, and I appreciate his support in
helping me keep things in perspective. I also want to acknowledge the support
of my management—Larry Abrahams, Maxine Erlund, Sharon Liu, and Stephen
Pelletier—who understood how important this project was to me.

My peers in the Java security development team participated in this publication

in many ways, and I wish to acknowledge them for their content contributions,
insights, patience, camaraderie, constructive criticism, and most of all their
friendship. Thank you, Alan Bateman, Jean-Christophe Collet, Jaya Hangal,
Charlie Lai, Rosanna Lee, Jan Luehe, Seema Malkani, Ram Marti, Michael
McMahon, Sean Mullan, Jeff Nisewanger, Yu-Ching Peng, Chok Poh, Vincent
Ryan, Scott Seligman, Andreas Sterbenz, Mayank Upadhyay, Yingxian Wang, and
Brad Wetmore.

Being a part of the team that created something that has had such a significant
impact on computing is an honor not shared by many. The success of Java is
obviously a result of the high caliber of people who made it a reality. I have had
the luxury of working alongside many talented people, and I expressly want
to thank Lars Bak, Josh Bloch, Gilad Bracha, Zhiqun Chen, Steffen Garup, James
Gosling, Graham Hamilton, Mark Hapner, Stanley Ho, Peter Jones, Peter Kessler,
Tim Lindholm, Ron Monzillo, Hans Muller, Hemma Prafullchandra, Mark
Reinhold, Rene Schmidt, Bill Shannon, Bob Scheifler, Jim Waldo, and Ann
Wollrath for the great experience, mentoring, and technical challenges.

Few people realize the existence and close working relationship the Java security
development team at Sun Microsystems maintains with our peers in other
organizations. I specifically wish to acknowledge the team at IBM, including
Larry Koved, Marco Pistoia, Tony Nadalin, and Bruce Rich, who have been
instrumental in enhancing the feature set of the Java 2 security architecture.

As new technologies emerge, we have worked closely with security researchers

within Sun Labs to integrate and productize their output. I wish to acknowledge
Anne Anderson, Whitfield Diffie, Steve Hanna, Susan Landau, and Radia
Perlman for passing along best-in-breed security technology.

I also want to thank the many reviewers of this text and specifically recognize
Gilad Bracha, Matt Curtin, James Hoburg, Peter Jones, Charlie Lai, Brian Larkins,
Rosanna Lee, John Linn, Ram Marti, Doug Monroe, Sean Mullan, Shivaram
Mysore, Vincent Ryan, Bob Scheifler, Andreas Sterbenz, Brad Wetmore, and Phil
Yeater for the feedback they provided. I also wish to recognize Peter Jones and
Shivaram Mysore for their content contributions.

Thanks also to Alan Sommerer, the Sun Microsystems Manager of Technical

Publications for the Java platform, for his help in ushering this book to
publication.

Finally, I want to express my gratitude to the production team. I thank the copy
editor, Evelyn Pyle, and the production folks at Addison-Wesley for their support
and effort in getting this book off my laptop and into print. Thanks to Marcy
Barnes, Jacquelyn Doucette, Amy Fleischer, John Fuller, Mike Hendrickson,
Michael Mullen, and Ann Sellers. Also, I want to acknowledge Mary Darby and
Amy Girard from Duarte Design for their innate ability to take my graphically
challenged images and turn them into a thousand words.

Gary Ellison
San Mateo, California
March 2003

I am grateful to all past and current members of the Java Security and
Networking group at Sun, as well as contributors from all over the world, who
continue to strengthen Java's position as the premier computing platform in
these areas. I am in debt to Gary Ellison and Mary Dageforde for their
tremendous effort in producing this second edition which significantly expands
the coverage of the first.

Li Gong
Beijing, China

It has been a pleasure working with Gary Ellison on this book. I thank him for
his vision, dedication, encouragement, feedback, enormous effort in the face of
multiple competing responsibilities, and sense of humor. It has also been my
good fortune to work with Li Gong and members of the top-notch Java Security
and Networking team at Sun at various times throughout the past several years.
I thank them all. Thanks also to Lisa Friendly of Sun and Mike Hendrickson of
Addison-Wesley for their support and their roles in facilitating publication of
this book. Finally, I would like to thank the copy editor, the graphics designers,
and the very helpful production folks at Addison-Wesley.

Mary Dageforde
Santa Clara, California

About the Authors

Li Gong is Managing Director of Sun Microsystems' Engineering and Research
Institute in Beijing, China. Previously at Sun, he was engineering head of Java
Security and Networking, Java Embedded Servers, and JXTA. He obtained B.S.
and M.S. degrees from Tsinghua University, Beijing, and a Ph.D. from the
University of Cambridge. He is Associate Editor-in-Chief of IEEE Internet
Computing.

Gary Ellison is a Senior Staff Engineer at Sun Microsystems, where he designs

secure network computing platforms. His primary role is focused on aspects of
trust, security, and privacy. From 1999 through 2002, he led the architecture,
design, and implementation of the security and networking components in the
Java 2 Platform, Standard Edition. He holds a B.Sc. in Mathematics and Physical
Science from The Ohio State University.

Mary Dageforde is a freelance consultant who writes software documentation

for various Silicon Valley computer companies, including Sun Microsystems.
She has an M.S. in Computer Science from Stanford University and a software
design and development background encompassing compiler and interpreter
implementation, language design, and database management. Since 1990, she
has concentrated on documenting APIs, languages, tools, and systems. She
wrote the Security trail of The Java™ Tutorial Continued (Addison-Wesley, 1999).
Preface to the First Edition

Give me a lever and a fulcrum, and I can move the globe.

—Archimedes

Since Java technology's inception, and especially its public debut in the spring
of 1995, strong and growing interest has developed regarding the security of
the Java platform, as well as new security issues raised by the deployment of
Java technology. This level of attention to security is a fairly new phenomenon
in computing history. Most new computing technologies tend to ignore security
considerations when they emerge initially, and most are never made more
secure thereafter. Attempts made to do so typically are not very successful, as
it is now well known that retrofitting security is usually very difficult, if not
impossible, and often causes backward compatibility problems.

Thus it is extremely fortunate that when Java technology burst on the Internet
scene, security was one of its primary design goals. Its initial security model,
although very simplistic, served as a great starting place, an Archimedean
fulcrum. The engineering talents and strong management team at JavaSoft are
the lever; together they made Java's extensive security architecture a reality.

From a technology provider's point of view, security on the Java platform focuses
on two aspects. The first is to provide the Java platform, primarily through the
Java Development Kit, as a secure platform on which to run Java-enabled
applications in a secure fashion. The second is to provide security tools and
services implemented in the Java programming language that enable a wider
range of security-sensitive applications, for example, in the enterprise world.

I wrote this book with many purposes in mind. First, I wanted to equip the
reader with a brief but clear understanding of the overall picture of systems and
network security, especially in the context of the Internet environment within
which Java technology plays a central role, and how various security
technologies relate to each other.

Second, I wanted to provide a comprehensive description of the current security

architecture on the Java platform. This includes language features, platform
APIs, security policies, and their enforcement mechanisms. Whenever
appropriate, I discuss not only how a feature functions, but also why it is
designed in such a way and the alternative approaches that we—the Java
security development team at Sun Microsystems—examined and rejected. When
demonstrating the use of a class or its methods, I use real-world code examples
whenever appropriate. Some of these examples are synthesized from the Java 2
SDK code source tree.

Third, I sought to tell the reader about security deployment issues, both how an
individual or an enterprise manages security and how to customize, extend, and
enrich the existing security architecture.

Finally, I wanted to help developers avoid programming errors by discussing a

number of common mistakes and by providing tips for safe programming that
can be immediately applied to ongoing projects.

Acknowledgments for the First Edition

It is a cliche to say that writing a book is not possible without the help of many
others, but it is true. I am very grateful to Dick Neiss, my manager at JavaSoft,
who encouraged me to write the book and regularly checked on my progress. Lisa
Friendly, the Addison-Wesley Java series editor, helped by guiding me through
the writing process while maintaining a constant but "friendly" pressure. The
team at Addison-Wesley was tremendously helpful. I'd like particularly to thank
Mike Hendrickson, Katherine Kwack, Marina Lang, Laura Michaels, Marty
Rabinowitz, and Tracy Russ. They are always encouraging, kept faith in me, and
rescued me whenever I encountered obstacles.

This book is centered around JDK 1.2 security development, a project that lasted
fully two years, during which many people inside and outside of Sun
Microsystems contributed in one way or another to the design, implementation,
testing, and documentation of the final product. I would like to acknowledge
Dirk Balfanz, Bob Blakley, Josh Bloch, David Bowen, Gilad Bracha, David
Brownell, Eric Chu, David Connelly, Mary Dageforde, Drew Dean, Satya Dodda,
Michal Geva, Gadi Guy, Graham Hamilton, Mimi Hills, Ted Jucevic, Larry Koved,
Charlie Lai, Sheng Liang, Tim Lindholm, Jan Luehe, Gary McGraw, Marianne
Mueller, Tony Nadalin, Don Neal, Jeff Nisewanger, Yu-Ching Peng, Hemma
Prafullchandra, Benjamin Renaud, Roger Riggs, Jim Roskind, Nakul Saraiya,
Roland Schemers, Bill Shannon, Vijay Srinivasan, Tom van Vleck, Dan Wallach,
and Frank Yellin. I also appreciate the technical guidance from James Gosling
and Jim Mitchell, as well as management support from Dick Neiss, Jon
Kannegaard, and Alan Baratz. I have had the pleasure of chairing the Java
Security Advisory Council, and I thank the external members, Ed Felten, Peter
Neumann, Jerome Saltzer, Fred Schneider, and Michael Schroeder for their
participation and superb insights into all matters that relate to computer
security.

Isabel Cho, Lisa Friendly, Charlie Lai, Jan Luehe, Teresa Lunt, Laura Michaels,
Stephen Northcutt, Peter Neumann, and a number of anonymous reviewers
provided valuable comments on draft versions of this book.

G. H. Hardy once said that young men should prove theorems, while old men
should write books. It is now time to prove some more theorems.

Li Gong
Los Altos, California
June 1999
Chapter 1. Computer and Network
Security Fundamentals

The three golden rules to ensure computer security are: do not own a
computer; do not power it on; and do not use it.

—Robert (Bob) T. Morris

Security is all about ensuring that bad things do not happen. This deceptively
simple brief statement can in fact have very complicated interpretations.
Exploring them can help in understanding what security really means.

Certain rule-of-thumb principles apply to the concept of security in general.

Throughout this book, you will see that these heuristics apply equally well to
computer security. First, security is always related to utility. To ensure that bad
things do not happen, you can simply do nothing. For example, a car stored in a
garage cannot cause a traffic accident. But doing nothing with the car is clearly
not what is intended. The real goal is to ensure that bad things do not happen
but that good things do get done.

Second, security is relative to the threat that one considers. For example, the
effectiveness of your house's locked front door to prevent theft depends heavily
on the types of thieves against which you are guarding. Although the lock might
deter an amateur thief, it might not pose a problem for a sophisticated one
equipped with the right tools.

Third, security must be considered from an overall system point of view. A

system is only as secure as its weakest point. That is, it is not enough to secure
only the front door. A skilled thief will try to enter the house from all potentially
weak spots, especially those farthest away from where you have installed strong
locks. It is of little use to install a deadbolt on a screen door.

Fourth, security must be easy to accomplish. If it takes 30 minutes and great

effort to unlock a complicated lock, you will tend to leave the door unlocked.
Fifth, security must be affordable and cost-effective. For example, it clearly does
not make sense to install a lock that is worth more than the contents it is
guarding. This is made more difficult to gauge due to the fact that the value of
something is subjective.

Last, but not least, security measures must be as simple as possible to

comprehend because, as experience indicates, the more complex a system is, the
more error-prone it tends to be. It is better to have something that is simple and
trustworthy than something that is less dependable due to the complexity of
building a comprehensive system.

1.1 Cryptography versus Computer

Security
Before moving on to specific topics, we want to clarify that cryptography and
computer security are two distinct subjects. Cryptography is the art of encoding
information in a secret format such that only the intended recipient can access
the information. Cryptography can also be applied to supply proofs of
authenticity, integrity, and intent. The use of cryptography has progressed
extensively over a long period of time, ranging from the ancient Caesar cipher
to cipher machines widely used in World War II to modern cryptosystems
implemented with computer hardware and software.

Computer security is the application of measures that ensure that information

being processed, stored, or communicated is reliable and available to authorized
entities. Computer security first became an issue only in the 1960s, when
timesharing, multiuser computer operating systems, such as Cambridge's early
computing system [133] and MIT's Multics [110], were first built. After that, the
field of computer security remained relatively obscure for years, apart from a
brief active period in the mid-1970s [5, 51, 57, 116]. Security concerns then were
based mostly on military requirements. Commercial security did not become
fully mainstream until the Internet and electronic commerce (e-
commerce)—and Java technology in particular—took center stage in the 1990s.

Security mechanisms often can benefit from the use of cryptography, such as
when running a network-based user login protocol. However, they do not
necessarily depend on the use of cryptography, such as when implementing
UNIX-style access control on files.

Yet cryptography does not exist in a vacuum. Cryptographic algorithms are

usually implemented in software or hardware; thus, their correct operation
depends critically on whether there is an adequate level of system security. For
example, if lack of access control means that an attacker can modify the
software that implements the algorithm, the lack of security directly impacts
the utilization of cryptography.

1.2 Threats and Protection

In computer security literature, threats or attacks are usually classified into
three categories.

1. Secrecy attacks. The attacker attempts to steal confidential information,

such as passwords, medical records, electronic mail (e-mail) logs, and
payroll data. The methods of attack vary, from bribing a security guard to
exploiting a security hole in the system or a weakness in a cryptographic
algorithm.

2. Integrity attacks. The attacker attempts to alter parts of the system

illegally. For example, a bank employee modifies the deposit system to
transfer customer money into his own account, thus compromising
transaction integrity [96]. Or, a college student breaks into the college
administration system to raise her examination scores, thus
compromising data integrity. An attacker might also try to erase system
logs in order to hide his footprint.

3. Availability attacks. The attacker attempts to disrupt the normal

operation of a system. These are also commonly called denial-of-service
attacks. For example, bombarding a machine with a large number of IP
(Internet Protocol) packets can effectively isolate the machine from the
rest of the network. A cyberterrorist might attempt to bring down the
national power grid or cause traffic accidents by compromising the
 computer-operated control systems.

These three categories of attacks are intricately related; that is, the techniques
and results of attacks in one category can often be used to assist attacks in
another. For example, by compromising secrecy, an attacker could obtain
passwords and thus compromise integrity by gaining access to and then
modifying system resources, which in turn could lead to successful denial-of-
service attacks. When a system failure occurs during an attack, most systems
are not fail-safe—that is, they do not enter into a state that is deemed
secure—because they are not designed to do so [111]. For example, it has been
shown that a system crash sometimes leads to a core dump in a publicly readable
directory, where the core can contain sensitive information if the dump occurs
[1]
at the right time.

[1]
Of course, attacks can be viewed from other perspectives. For
example, there is widespread public concern about the privacy of the
unregulated and sometimes illegal collection and distribution of
personal data, such as birth dates and U.S. social security numbers.

Similarly, protection mechanisms against these types of attacks in general are

related. Roughly speaking, the mechanisms are for one or more of the following
purposes: attack prevention, detection, or recovery. Not all these purposes can be
fulfilled by the same mechanisms, as explained later in this chapter.

To protect data secrecy, you can store the data in an obscure place in the hope
that attackers will not find it. Or you can install strict access control procedures
to guard against unauthorized access. Or you can use encryption technology to
encrypt the data such that attackers cannot access real data unless they can steal
the encryption key or can break the cryptosystem, which could be extremely
difficult. Of course, multiple measures can be deployed at the same time. Note
that, for secrecy, the most important technique is prevention. A loss of data is
very difficult to detect, and lost data is impossible to recover.

To protect data integrity, you can use any or all the mechanisms mentioned
previously. However, in this case, detection is easier, and recovery is often
possible. For example, you could compute the hash value for a file x, using a
wellknown one-way function f(), and store f (x) separately. If x is then modified
to be x', f (x) very likely will not be equal to f (x'), according to the properties of f().
Thus, you can recompute the hash value and compare it with f (x). A mismatch
will indicate that integrity has been compromised. See Section 1.5.1 for more
information on one-way hash functions.

Of course, if the corresponding f (x) is also compromised, detection might not be

possible. If the place to store f (x) itself is not safe, you could use a keyed, oneway
hash function and store f (k, x) together with x. If k is kept secret, it will still be
difficult for attackers to modify x and the hash value in such a way as to avoid
detection [39, 83].

To be able to restore the data to its original form after an integrity compromise,
you can back up data and store the backup in a secure place [96]. Or you can use
more complicated distributed computing techniques to back up the data in an
insecure network [53, 98, 114, 118].

Guarding against an availability attack is more complicated. The reason is that

apart from applying the usual techniques of prevention and detection, surviving
such attacks becomes critical. Here, computer security meets the field of
faulttolerant computing. Some interesting research results in this combined
topic area, sometimes called dependable systems, are available. For further
reading, consult the papers and their citations at [24, 42, 99, 114].

1.3 Perimeter Defense

Because of the multitude of potential weaknesses and the essentially unlimited
number of attack scenarios, whereby each scenario can be a combination of
various attack techniques, securing an entire system can be daunting, especially
when the system includes multiple host machines connected via a network.
Because a system is only as secure as its weakest link, the security coverage must
be comprehensive. The task is further complicated by the fact that a system—for
example, the internal network deployed within a large enterprise—typically
consists of machines of numerous brands and types. These machines run
different operating systems and different application software and are
connected with routers and other networking gears from various vendors
offering differing features and capabilities. In such a heterogeneous and
evolving environment, examining the entire system and securing all its
components—if possible at all—takes a long time.

Faced with such a messy picture, it is no surprise that companies find it easier,
both psychologically and physically, simply to divide the world into two camps:
"us" and "them." "Us" includes all machines owned, operated, or, in general,
trusted by the concerned enterprise, whereas "them" includes all other
machines, which are potentially hostile and cannot be trusted. Once the border
is drawn, it is a matter of keeping "them" out and "us" in. Such a defensive
posture is often called perimeter defense.

One approach to constructing a perimeter defense is simply not to connect "us"

with "them." Indeed, some military installations and commercial entities have
internal networks that are entirely separated from a wider area network: the
Internet, for example. They might allow some isolated terminals or machines for
outside connections, but these special machines are usually guarded to prevent
their being connected to the internal network.

If the overall system contains machines scattered among physical or

geographical locations, leased lines or dedicated network connections can link
the sites to form a private network. If, however, the sites must communicate
through the open network, encryption can be deployed between every two
communicating sites so that they form a virtual private network (VPN). This
is depicted in the fictitious scenario in Figure 1.1, where, although all four
campuses are connected to the Internet, three sites (MIT, UT Austin, and UCLA)
have firewalls deployed and have also formed a VPN so that network traffic
among them is automatically protected from eavesdropping.
 Figure 1.1. Perimeter defense

However, such total isolation from the outside does not always work well. For
example, e-mail has become the "killer application" of the Internet as people
increasingly demand the ability to communicate with the outside world via
the Internet. The World Wide Web (the Web) has made the Internet even more
popular, and—if used judiciously, of course—browsing the Web to locate
information is important to productivity. These trends are driving previously
closed enterprises to open up their border control selectively. Here is where
firewalls play a critical role in constructing a more useful perimeter defense.

1.3.1 Firewalls

Firewalls come in different shapes and sizes [8]. Generally speaking, as

illustrated in Figure 1.2, a firewall is a machine sitting between a private
network and a public one. A firewall functions as a filter for network traffic,
with the responsibility of selectively allowing certain traffic through, in each
direction, based on a security policy. A security policy can be very simple or
quite complicated. The reason is that filtering decisions are often based on, for
example, the source and destination of the traffic, the protocols used, and the
applications involved, among other factors. The firewall also might redirect
traffic, act as a proxy server, or even manipulate the traffic content before
allowing it to pass through. Furthermore, the firewall might encrypt traffic;
indeed, encrypting firewalls can be used to form a VPN.

Figure 1.2. Firewall deployment

Perimeter defense as implemented by firewalls has been shown to be an effective

security solution. A firewall provides a central point of control, so a corporate
policy can be more easily implemented and updated. But a firewall has certain
problems. First, firewalls cannot filter or stop all network traffic. In fact, traffic
for such protocols as HTTP (Hypertext Transfer Protocol) is often deliberately let
through firewalls. Generally, there is tension between the firewall and the utility
the network provides. The firewall attempts to block or reduce unwanted traffic,
whereas the primary benefit of the network is its ability to exchange all forms of
traffic. A firewall can also be a bottleneck and a single point of communication
failure. Moreover, many applications on the desktop have to be rewritten to use
the firewall as a proxy. This problem is less severe for new applications, which
often have built-in proxy support.

1.3.2 Inadequacies of Perimeter Defense Alone

Perimeter defense alone is not sufficient, however, as a total security solution,

for several reasons. Locating and securing all perimeter points is quite difficult.
In reported cases, direct telephone line–based connections are established, for
diagnostic purposes, that can effectively puncture the perimeter defense [96].
Further, when an enterprise allows its employees to work remotely and from
home, inspecting and ensuring that the remote entry points to the internal
network are adequately protected may be impractical.

Even within an enterprise, controls are needed because not everything or

everyone can be fully trusted. The most devastating attacks often occur from
within. Such insider attacks usually incur comparatively large losses because
insiders have a significant advantage over external attackers. For example, the
accounting department must be protected so that only authorized employees
may issue purchase orders, whereas the patent department must be isolated to
prevent information leaks to competitors.

The remainder of this chapter reviews security models and techniques that are
useful both within the perimeter and across organizational boundaries.

1.4 Access Control and Security

Models
A security model is an abstraction of how one goes about controlling access
to protected data. Like firewalls, security models come in various shapes and
sizes because requirements for various applications and their environments can
differ vastly. Multiple ways to classify security models are available, including
the following:
 • MAC and DAC models

• Data and information security models

• Static and dynamic models

1.4.1 MAC and DAC Models

One classification of security models centers on the concept of mandatory access

control, or MAC. In a MAC security model, entities within a system are either
subjects, roughly corresponding to the notions of users, processes, machines, and
so on, or objects, roughly corresponding to the targets of control, such as files
and data records. Each entity is assigned a sensitivity level. Such levels normally
form a lattice over a "dominate" relationship so that, for example, if there are two
levels, either one dominates the other or the two are incompatible. For example,
levels of "classified," "secret," and "top-secret" could have the dominate
relationship shown in Figure 1.3.
 Figure 1.3. MAC security model

MAC models meeting the requirements of multilevel security are exemplified

by the work of Bell and LaPadula [5], describing a mathematical model for the
security of the Multics system [110]. In the Bell-LaPadula model, a subject may
have read access to an object if, and only if, its level dominates that of the object
and may have write access to an object if, and only if, its level is dominated
by that of the object. This is called informally read-down and write-up, or more
precisely, no read-up and no write-down. According to this model, two entities
may communicate in both directions only when either they are at the same level
or they do so via a trusted intermediary.

Non-MAC models are called discretionary access control, or DAC, models. The
UNIX security model is similar to a DAC model in that the owner (user) of each
file can determine who else can access it by setting the file's permission bits.
Someone who can read a file can also make a copy of it and then let everyone read
it. MAC models do not permit such discretionary decisions.
Exploring the Variety of Random
Documents with Different Content
The text on this page is estimated to be only 28.73%
accurate

BREWING. 539 A. J. Brown, however, has proved (J. Inst.

Brewing, 1907, 13, 658) that when undamaged barley corns are
steeped in either hard or soft waters the salts dissolved only
penetrate the outer thick coverings of the grain, and the first thin
skin, or pericarp, but are arrested by the second thin skin, or testa,
which immediately surrounds the germ and endosperm, only pure
water entering the grain. Hence the action of steep water is limited
to the external envelopes of the grain, and the matter extracted
during steeping (varying from 0-5 to 1-5 p.c.) must be considered to
be derived in its entirety from the skins of the barley corn. Working
on these lines, H. Seyffert (Zeitsch. ges. Brauw. 1907, 30) finds that
the carbonates of the alkali earths (sodium, magnesium, and
calcium) act on the tannin and bitter principles of the husks (the
effect being to remove them or render them harmless), giving the
malt an aroma and greater sweetness. This author considers very
soft waters unsuitable for steeping, and only give good results with
very fine thin-skinned barleys, for the greater the carbonate content
of the water, the less stress need be placed on the quality of the
barley. Moufang and L. Vetter confirm the views of Seyffert, and also
add that calcium sulphate and sulphuric acid in steep water cause
the husk constituents to adhere more firmly to the fibre of the husk,
so that these substances can only be removed by subsequent
treatment with alkaline water. Matter in solution in the steep water,
however, enters damaged corns, and loss of extract from the interior
of the grain takes place in any type of water, which fact strengthens
the objection to the damages of close threshing. It will be seen,
then, that, contrary to previous views, the most favourable water for
steeping is one containing alkaline carbonates. The temperature of
the steep water considerably effects the rate at which the grain
absorbs water, and also the speed of germination on the floors. The
warmer the water, the more rapid is the absorption, and the quicker
the start of germination. The temperature usually adopted in
England is 50°-55°F., and care should be taken to see that this is
kept constant, in order to preserve regularity of water content and
growth. The use of lime water in the steep has been recommended
by Windisch to improve germination and to avoid mould formation
on the floors. This has been found to give good results, the lime
water being used in the first change only. 16. Malting. At present
three systems of making malt are practised : (1) English system. (2)
Continental. (3) Pneumatic. The English system briefly consists in
steeping the grain in water in large iron or stone cisterns, draining
the water off, spreading the moistened grain in thin layers upon
exposed floors and drying upon an open fire kiln at a period of from
9 to 21 days from time of steeping. The continental system differs
materially in all the above details. Pneumatic malting provides for
absolute control over the admission of air supplied to the
germinating grain. Briefly the system is as follows : The grain is first
steeped in the same manner as in the English floor system. It is then
transferred to the interior of a metal cylinder or drum, which is
rotated slowly in order to keep the growing barley on the move,
whilst moist air is blown through the grain from a central duct ; by
this means absolute control of temperature and humidity is obtained,
and the necessity for sprinkling is obviated ; when the piece (as the
drum load of growing barley is termed) has grown to the desired
extent it is either transferred to an ordinary kiln or dried in the same
drum, hot air being blown through instead of cool moist air until the
piece is sufficiently cured. The simplest form of malthouse
possessing any capacity for work is a plain two-story building having
attached to it a kiln or dryinghouse, and consisting of a ground-floor
of clunch, a brick steeping cistern, and a first floor of timber with or
without partitions for separating the stored grain or malt ; but a
good malthouse of fair size is most conveniently and favourably
worked if it consists of one main building of three stories — two kilns
and a corn or malt store. The growing floor may be composed of a
variety of materials, but that which is most to be preferred is either
cement concrete worked to a perfectly smooth face, or plain
unglazed red tiles, well set in cement. The cistern should always be
at the end opposite to the kiln in a single-floor house, and so
arranged that entire control of the temperature of the steep liquor
can be secured, and that the grain can be readily screened into them
when filled with water to enable the thin corn and refuse to float off.
The water supply should be so arranged that it can be run in from
below and overflow at top prior to a charge of steep liquor, and a
number of inlet and outlet pipes, all fitted with strainers, should be
fixed. There should be in addition a series of perforated pipes, by
means of which water can be sprayed or sparged from above over
the grain like a shower. The cisterns are emptied of the steeped
grain either by shovelling on to the floor, if on the same level, or by
running down through shoots in the bottom to the floor below.
Cisterns 'are generally built of concrete, brick, or iron. An excellent
form of construction is afforded by the use of the Hygeian Rock
cement, as shown in Fig. 5. This method gives a wall only 9 inches
thick, but quite strong enough for all practical purposes ; the outside
wall of the cistern is generally coated with cement, whilst the interior
of the cistern is preferably lined with white glazed or enamelled
bricks well set in cement. Brick or concrete cisterns should have a
wide central channel running their full length. The top of the channel
must be framed to receive perforated iron plates or tiles to serve as
strainers. Iron cisterns are best made square in shape, with a conical
bottom with a valve at the apex to discharge the wet FIG. 5.
The text on this page is estimated to be only 28.49%
accurate

540 BREWING. grain, the draw-off cock for the steep water
being fixed as close to the valve as possible, and being covered with
a perforated plate to prevent the barley corns being drawn off with
the water. Such cisterns are usually fixed above the growing floor,
and the grain is discharged directly on to it. The capacity of these
cisterns should be ample enough to steep the utmost quantity of
corn the floor can possibly grow in the coldest weather ; not less
than 14 cubic feet per quarter should be allowed when calculating
their dimensions. The kiln should be a lofty and roomy structure,
preferably of brick, with a high roof surmounted by a cowl. The area
of the drying floors should never exceed one-fourth or be less than
one-sixth of the growing floors, nor should the combined air inlets
and discharges bear a ratio to each other exceeding that of 4 to 5.
In practice it is found that the more closely a kiln resembles a
chimney in construction, the greater is its effective capacity,
consequently the tendency has been constantly to increase the
height of the kilns. Kilns may be of various forms, but a square one
is undoubtedly the best. In Fig. 6 is shown a type of kiln at one time
very common in Great Britain. FIG. 6. In every portion of the plant
connected with malting, great diversities of size and style occur, and
kiln furnaces offer no exception to the rule. Generally malt-kiln
furnaces either permit the products of combustion to pass through
the malt whilst drying, or they do not do so. The form of furnace,
perhaps, most in vogue in this type of kiln is known as the fire-
basket. This is a large open cast-iron basket of from 3 to 6 ft.
square, with legs or supports carrying a frame fitted with ordinary
fire-bars and thick sloping sides. These baskets are sometimes
placed merely upon the bottom floor of the kiln with no protection of
any kind, others are built over with a brick arch left full of holes for
the escape of heat on all sides. A in Fig. 6 shows the form of fire-
basket usually employed, the spaces BB at the sides of the furnace
are used as coal or fuel stores. The drying floor c is built at all
heights, ranging from 5 to 29 ft. above the furnace, and is generally
made of earthenware FIG. 7. perforated tiles resting on light iron
bars, whicl in their turn are supported by larger joists. The
construction of the roof D is of great importance, as very much
depends on it ; if the pitch is not at the proper angle, the drying of
the malt is affected to a certain extent ; cross timbers are
objectionable, and should be avoided as far as possible; lath and
plaster forms the best lining to the slate roof, as well as for the sides
of the drying chamber. The cowl B is the usual form of outlet to
The text on this page is estimated to be only 28.69%
accurate

BREWING. 541 this type of kiln. In 1881 the first kiln in

England with two floors, and known as Stopes's system (Fig. 7), was
erected by Messrs. Taplin & Sons, at Brighton, which gave very
satisfactory results, and is used by many breweries in this country. It
is claimed that two-floor kilns possess several advantages, of which,
probably, the chief are the regularity of temperature upon both
floors and the economy of fuel and labour. The modern type of kiln
is illustrated in Fig. 8. With this type the furnace A consists of a
square chamber lined with fire-brick, and furnished with ordinary
fire-bars. The temperature of the upward draught is regulated by
iron plates which control the air inlets FIG. 8. oa above the fire. The
hot air and products of combustion pass up the shaft, and are
distributed evenly over the drying floor c by the brick and concrete
baffle B, supported on short brick pillars. The drying floor c is
composed of steel wire. The cowl is replaced by a shaft D, provided
with louvre boards, and a fan E to control the force of the upward
draught is fixed at the base of this shaft. The spaces FF are used as
a malt stores. 17. Steeping. The cistern should be filled with the
steep water, then the barley slowly run through a shoot into the
cistern ; by this means the dirt and dust, small and light corns, and
other matters find their way readily to the surface and may be
skimmed off. This first steep water should be run off within the first
six hours, it being the most impure ; the succeeding steep water
should be changed every twelve to twenty-four hours, according to
temperature and season of year. Sufficient time must be allowed
between running off the old and running on the fresh water to allow
the barley to become well aerated. In some maltings air is pumped
into the barley whilst it is steeping in the water. The first steep water
should be run off from above, and the second water run in from
underneath ; this upward filtration serves very effectually to cleanse
the grain from any adhering impurities. Some maltsters sparge on
the steep water through sparge arms fixed above the cistern,
thereby aiding aeration considerably. The grain is allowed to remain
in steep for a period of forty to seventy hours, depending upon
surroundings ; but the maltster would naturally be guided by the
temperature of the atmosphere, the quality, condition, and age of
the barley, high temperature necessitating more frequent changes of
steep water and shorter time in steep. Then, again, coarse, thick-
skinned, or heavy barleys would naturally require longer steeping
than the lighter and thinner kinds ; the older the barley, the longer it
requires to be steeped, as new barley germinates more quickly than
old, the chief object of steeping being to impart to the grain about to
be malted a sufficiency of moisture to ensure perfect and regular
germination. 18. Couching. Before the repeal of the malt tax the
barley, when taken out of steep, was placed in what was known as
the couch. This might be regarded as a dry cistern where the grain
had to lie a certain number of hours, or until it was gauged by the
excise officer and the duty levied. Since this has been done away
with, the couch is no longer needed, though even yet many
maltsters pile up the barley when taken out of steep in a heap for
twenty to twenty-four hours, indeed, until the growing point of the
rootlet begins to show. This is a great mistake. In the first place, a
greater amount of heat will be developed in the interior of the heap
than on the outside by the germinating grain, hence these corns will
grow more rapidly than the others, so that very uneven ' pieces ' on
the floors will be the result. It has also been proved that heat in
couch tends directly to produce acidity in the finished malt. After the
gram comes out of steep it requires all the oxygen it can get, as well
as the removal of the carbonic acid gas which becomes disengaged
by the process of germination ; this necessarily involves free contact
with air, and therefore it is advisable that couching be done away
with altogether. 19. Flooring. Where it is still practised, as soon as
germination is observed to have commenced, the couch is broken
down and the grain spread out on the floor, the depth at first varying
from 12 inches to about 3 or 4 according to season and
temperature; it is then left for from twenty to twenty-four hours,
when it is turned by means of a wooden spade. For the succeeding
two or three days it is either ' ploughed ' or turned about twice daily
; of course this entirely depends on the judgment and experience of
the maltster, his main object being to obtain a good bushy root and
a regular
The text on this page is estimated to be only 28.65%
accurate

542 BREWING. development of the acrospire. This requires

very careful and close attention on the part of the maltster, for
during ' flooring ' he has not only to control the development or
growth of the germinating grain, but the very nature of that growth.
He has to give air and secure ventilation, to regulate heat and
humidity, to foster the development of the acrospire, and check the
root growth, or vice versd as the case may be ; all this can only be
attained by long experience and an intelligent appreciation of
scientific facts. As a rule, English maltsters allow germination to
proceed until the acrospire has extended to about three-fourths the
length of the grain, the rootlets being at the same time about twice
the length of the grain, but this is varied considerably according to
the ideas of each individual maltster. Germination is accordingly
carried on until this stage is reached. About the fifth day from the
time of taking out of steep the grain is sprinkled at intervals with
water from a watering-can ; this is continued until the sixth day. The
quantity of water used for this purpose varies from three to six
gallons per quarter of barley, but of course will naturally depend
upon the state of the atmosphere as well as on the condition of the
piece. On the days of sprinkling the grain is turned four times each
day ; after the sixth day it is turned two or three times daily. As soon
as the germination has proceeded to such a degree as may be
desirable, it is subjected to the process of withering, the object
being to arrest germination, to increase the temperature of the piece
so that as large an amount of moisture as possible may be got rid of
preparatory to kilndrying. In many malthouses a proper withering
floor is provided, generally of wood. During this stage the sootlets
wither, becoming shrivelled and dry. As soon as this takes place,
many maltsters throw the green mait, as it is now called, into a
heap, and allow it to heat spontaneously, the object being to make it
tender. A piece which was sprinkled on the fifth and sixth days under
ordinary conditions should be ready to go on kiln on the tenth or
eleventh day. Some maltsters allow the piece to become almost dry,
not sprinkling until the eighth or even ninth day, but this cannot be
recommended. The grain at time of going to kiln is at most only
imperfectly withered, contains an excess of moisture necessitating
very frequent turning as well as encouraging the growth of mould on
kiln, and finally imparting a degree of hardness or steelinrss to the
finished malt which occasions diminished extract and possibly
starchy worts. If the barley whilst on the floors shows much, or in
fact any signs of mouldiness, both the cistern and floors must be
thoroughly well scrubbed with water to which 10 p.c. of good strong
calcium bisulphite has been added. When dealing with low-class, ill-
conditioned, or damaged gram, it is always well to add a suitable
quantity of bisulphite, both to the steep water as well as to the
water used for sprinkling. It is also essential that thermometers
should be placed at frequent intervals on the floors, and the
temperature carefully noted from time to time ; indeed, the question
of temperature is just as important a factor in malting as it is in
mashing. 20. Drying. By the time the germinated barley is ready to
go on the kiln, it really is in effect no longer barley but malt, or more
properly green malt, and has attained at this stage its highest
diastatic energy, so that if the object were merely the production of
diastase the malt might now be dried off at ordinary temperatures ;
but for the purposes of the brewer and distiller it is absolutely
necessary that this green malt be subjected to the influence of heat,
not only for the purpose of drying it completely and arresting
germination, but in order that certain changes may take place in the
chemical composition of its various constituents which are necessary
to impart flavour and other properties to the liquor brewed from it
and which we term beer. In addition to this, the malt also becomes
capable of lengthened storage, and when well dried is best adapted
for grinding and for transport ; also all mould and fungoid growths
are completely arrested and their vitality suspended. The
temperature employed in finishing off the malt on the kiln will
determine its quality, thus we may have pale malts, medium, and
highdried. For pale malt only the better qualities of barley should be
used, and great attention should be paid whilst on the growing floor
to prevent the development of mould ; also the withering off should
be carefully attended to, the principal object of the maltster being to
obtain a good healthy growth in the earlier stages, and that the
green malt should be as dry as possible at the time of going to kiln.
To dry pale malt well, Stopes says three things are necessary : (1) It
should be loaded in the condition just described as sound green malt
upon a floor at a thickness rarely, if ever, exceeding 7 to 8 inches.
(2) It must remain unturned at a low temperature until nearly all
moisture is removed. (3) Heat must then be applied steadily and
freely, and be maintained for a considerable time at a nearly uniform
temperature, ranging from 160° to as high as 230° in some cases.
Constant forking of the kiln at this period is necessary, otherwise
mould is specially liable to take place, and this should be persevered
in until the malt is sufficiently dry to be turned. On no account
should turning be resorted to until the malt is fairly dry to the touch.
To, ensure the carrying out of these points with greater accuracy
and less risk than is possible on an ordinary kiln, the employment of
a fan is requisite to create a motion of air through the malt, by
which means the moisture can be extracted at much lower
temperatures than would be possible under ordinary circumstances,
and without fear of putrefaction, whilst for uniformity of temperature
it is unequalled. As long as an appreciable amount of moisture
remains in the malt, it is most important that the temperature on
kiln should not exceed 120°, while special attention must be paid to
ventilation. When we consider that from 90° to 120° is the most
favourable range of temperature for the development of the
numerous
The text on this page is estimated to be only 28.25%
accurate

BREWING. 543 spores of various micro-organisms which,

despite all our efforts to the contrary, are to be found adhering to
the moist corns, and that with their development ensue chemical
changes, such as the production of various organic acids, which
most seriously affect the character of the malt, it would seem that
the shorter time the malt is exposed to this temperature the better ;
therefore it is advisable that the layer of malt should certainly not
exceed 8 inches, and it would be better still if it were only 6. But it is
not simply a question of drying the malt quickly at a low
temperature ; certain changes irrespective of those produced by
micro-organisms are brought about in the nitrogenous as well as in
the other constituents of the malt whilst submitted to these
conditions of temperature and moisture. As soon as the malt begins
to present a dry appearance, the temperature may be gradually
raised up to the final temperature at which it is to be finished off. It
is impossible to give a fixed limit for this, as a great deal will depend
upon circumstances, but, as a general rule, for pale malt the final
temperature may be taken at 200°F. From the time of raising the
temperature until the end of the process, the malt should be turned
at intervals. In drying the malt the great point to be observed is the
maintenance of a perfectly even ! temperature, so that the whole of
the malt drying should be at any given moment of the same uniform
temperature. In the old type of kiln the process of drying, from time
of going on to coming off kiln, usually occupies about four days, and
is distributed as follows : 1st day not below 80° or above 100°F. 2nd
„ „ 90° „ 110° 3rd „ „ 120° „ 130° 4th „ „ 140° „ 180°-185° For the
first two days the malt should on no account be turned, but the
surface forked over lightly, if needed. After the second day the malt
should be turned at frequent intervals. In the modern type of kiln
the drying process from the time of going on to coming off kiln
usually occupies three days, and is distributed as follows : — 1st day
not below 80° or above 100°F 2nd „ „ 100° „ 130° 3rd „ „ 130° „
200° The malt is not turned until the second day. As soon as the
green malt is loaded on the kiln, the fan is started rapidly, and by
this means a strong upward draught is induced which draws the
moisture rapidly from the malt ; as the latter becomes dry, the
temperature is increased, and the speed of the fan is reduced.
Medium and high-dried malts are finished off at much higher
temperatures, ranging from 200° to 230° and upwards. As soon as
the temperature gets up to the final point, this heat is in a great
many maltings maintained only for one or two hours. This is a great
mistake ; there can be no doubt that the longer the malt is erposed
to a high heat, the sounder and better keeping will be the resulting
beer. The final heat might certainly be attained in a shorter time
than it usually is, and the malt might be exposed to this heat for at
least 6 hours without undergoing any darkening in colour whatever.
Much the same method is pursued in the drying of the malt on
double-floor kilns as on single. The malt is first loaded on to the top
floor, where it is kept at a temperature not exceeding 120° until
about 90 p.c. of the moisture is driven off. It is then dropped
through doors or holes to the lower floor, where it is finally dried off
at a temperature of from 180° to 190° or more, and the same heat
and air that effect this are in fact the very best possible to drive off
the moisture from the upper floor, which in the mean time will have
been loaded with a fresh piece. It is hardly necessary to say that in
the process of kilndrying, where the temperature is the important
factor, several thermometers placed on each floor are absolutely
indispensable. The malt, after it is finished drj'ing, has yet to be
freed from the radicles or ' combes.' This used to be accomplished in
the old maltings by its being well trodden by men furnished with
heavy-soled boots ; the radicles being thus detached from the corns,
and by passing the malt over a ' water-fall ' malt screen it was
completely freed from these as well as from some of the adhering
dust. In modern maltings, as soon as the malt is thrown off the kiln,
it is passed through a brushing machine, each kernel being brushed
free from ' combes' and adhering dust. In some maltings, previous
to being brushed, the malt is heaped up in the centre of the floor
and remains so overnight with the fire well banked up. We may get
a very fair idea of the temperature at which the malt has been dried
by observing the colour of the combes. The higher the temperature,
the more highly coloured they become ; indeed, where it is almost
impossible to observe any difference in the colour of two malts dried
at different temperatures, an examination of the combes from these
malts shows it at once. 21. Storing. After freeing from the combes
by screening, malt is usually stored away in bins for some weeks
previous to use in the brewery. The floor, sides, and top of these
bins should be made of good seasoned wood and lined with sheet
sine. These bins are usually built in the driest part of the malthouse ;
this would naturally be in the neighbourhood of the kiln, and it
should be protected as much as possible from draughts. During this
storage of the malt previous to use some change certainly takes
place in its nitrogenous constituents ; in technical language, ' the fire
is taken out of it and the malt becomes mellow,' but, whatever these
changes are, nothing is known about them up to the present. All
that can be said is that it has been found decidedly unadvisable to
use any malt for brewing purposes until it has been stored for at
least six weeks from the time of coming off the kiln. 22.
Characteristics of malt. The following are the characteristics of a
good malt, as given by Slopes : — (1) Growth. The malt should be
evenly grown, the acrospire showing between two-thirds to three-
fourths up the back ; any malt which contains many corns showing
the acrospire protruding should be rejected. On the other hand,
The text on this page is estimated to be only 28.33%
accurate

544 BREWING. it should also not contain more than 4 p.c.

of ungerminated corns. (2) Slackness or moisture. This will vary to a
slight extent -with the age of the malt, but on the average, malt
should not contain more than 3 p.c. of moisture. (3) Age. Malt is at
its best from six weeks to four months ; after that time, under
ordinary conditions of storage, it gradually absorbs moisture and
becomes more or less slack. (4) Odour. Good malt should have a
pleasant, well-known aroma peculiar to itself. (5) Condition. This will
depend a good deal upon the quality of the barley. Good barley
badly managed may produce a bad malt, but a bad barley will never
produce a good malt. Good malt should be tender and friable when
broken, and should bite crisp and crumble readily under the teeth.
(6) Cleanliness. Malt should be comparatively free from mould and
dust as well as rootlets and inorganic refuse. 7. Flavour. The flavour
of malt is derived from influences of growth and of drying ; it should
possess a pleasant, mellow, sweetish taste, free from rawness on
the one hand, and bitterness on the other. Such are the
characteristics of a good malt so far as can be determined by the
eye, but these should always be supplemented by a complete
chemical analysis.1 By this means we obtain the following
information : — I. Actual composition : a. Starch products, as dextrin
and maltose. b. Cane sugar. c. Other sugars. d. Total albuminoids
soluble after boiling. e. Ash. /. Moisture. g. Insoluble matters or
grains. II. Relative diastatic capacit}\ III. Specific rotatory power. » A
brewer ought to have a fair idea of the constituents of his malt
before commencing to mash with it, for from such an analysis as
given above he will be in a position to predicate very fairly what kind
of wort and beer his malt is going to produce, and so be enabled to
control not only his mashing process, but all subsequent operations.
Other descriptions of malt, in addition to the kind we have hitherto
been considering, are made and used. These are : Brown or porter
malt. Amber malt. Black, roasted, chocolate, or patent malt. Brown
and amber malt are prepared practically in the same way as ordinary
malt until they go on kiln. Here they are dried at a much higher
temperature, and wood is largely used for the purpose instead of
coal or coke. Black malt is simply ordinary malt which is roasted in
exactly the same way as coffee berries are. ' A sample of properly
roasted malt is uniform in colour, of a chocolate hue, not black, and
each com clear and clean. If it is black, with the corns burst, and
especially if matted or run together, it is of a most inferior kind, and
neither good flavour nor permanent colouring can be expected from
it.' 1 For full details of latestmethpds of analyses of malt, worts, and
beer, v. Sugar, Saccharimetry. 23. Malt adjuncts. These may be
divided into two classes. First, those substances from which the
extract has to be obtained by the mashing process ; and second,
those in which the extract is already formed. Class I. Several grains
of cereals other than barley have been prepared for brewing
purposes, either by malting or subjecting to the action of heat in
some way or other. The principal of these which are at present used
as substitutes for malt, either in a prepared form or in the raw state,
are maize malt, germless maize, gelatinised maize, gelatinised rice,
torrefied grain or white malt, and in the raw state barley, rice, and
maize. When using any of these substances for brewing purposes,
certain proportions of them are either mixed with the malt in the
mash tun, or else the starch contained in them is first gelatinised in
a separate vessel and rendered soluble by the addition of a little
malt, and afterwards added to or sparged over the goods in the
mash tun. Class II. Under this head are included ordinary cane
sugar, invert sugar, glucose or starch sugar, and dextrin-maltose.
Raw cane sugar cannot be recommended as a brewing material,
owing to the large quantities of impurities of a dangerous character
which are always present. Refined cane sugar is used to a certain
extent, but before it can undergo fermentation it has first to be
hydrated or inverted by a peculiar unorganised ferment contained in
the yeast and termed invertase, and as this reaction tends to
weaken the yeast to a certain extent as well as favour the
production of lactic acid, it has been found more advantageous to
use cane sugar which has been previously inverted. This is done by
means of sulphuric acid, which is afterwards neutralised with calcium
carbonate, and the inverted • sugar freed from the calcium sulphate
by filtration is further purified by being passed over animal charcoal,
and then boiled down under diminished pressure to a thick syrup, in
which state it is sent out by the manufacturer. 24. Hops. The hop
plant belongs to the nettle family, and is a perennial climbing or
rather twining plant. It is found hi the wild state all over Europe, and
is propagated not by seed but by sets or suckers thrown up from the
root, which is perennial, the stems dying down at the approach of
whiter, and fresh ones coming up each spring, and often attaining a
height of 30 feet or even more. The hop plant bears two distinct
kinds of flowers, male and female, and these flowers again are
produced on distinct plants ; of these only the plant bearing female
flowers is cultivated, the male plant being rigidly excluded from most
hop plantations. The flowers, which are the only parts of the plant of
any use to the brewer, occur in the form of peduncles or cones,
consisting of a series of scales or carpels lying above each other so
as to form a cone. On the inner side and on the lower edge the
carpel is turned over and encloses at first the female flower and
afterwards the fruit developed from the flower. The fruits of the hop
are round hard granules or little nuts; these fruits and the inner
sides of the scales are thickly covered with a fine yellow dust — the
socalled lupulin. Under the microscope this dust
The text on this page is estimated to be only 27.68%
accurate

BREWING. 545 is seen to consist of numberless granules,

these granules being composed of glands, which are formed by the
union of several simple cells. These glands are hollow, and this
hollow space is filled with hop oil, resin, bitter principle, &c. As a
rule, the value of the hop may roughly be determined by the
quantity of lupulin it contains. In practice the quantity of the hop
flour present — the ' condition,' as it is called — is roughly estimated
by rubbing the hops between the hands, the amount of stickiness
left forming an index as to the quantity of lupulin present in the
hops. Hops are principally cultivated in the counties of Kent, Surrey,
Sussex, and Worcester. The Kent hops are in much repute, and more
especially that variety known as Golding, being rich and delicate in
flavour ; the Sussex hops are somewhat coarser in flavour than
Kent, and perhaps do not present such a pleasing appearance to the
eye, but nevertheless are good useful hops for running beers or for
mixing with Kents for higher-class ales. Worcester hops are milder
than the above, and in some breweries much preferred to any other.
Of late years bad seasons and the attack of the hop aphis have done
much to deteriorate the quality of English hops, so that at present
large quantities are imported from Germany and America ; but
foreign hops lack that delicate aroma and flavour peculiar to English
growth, and are as a rule only used for the lower quality beers.
Hops, in order to be kept for any appreciable time, require to be
thoroughly dried ; the hop cones, after they are picked, are spread
out on the floor of a kiln, where they are dried by artificial heat.
Sulphur is often sprinkled on the kiln fires, and the sulphurous acid
gas thus produced passing through the hops bleaches them, so that
hops naturally dark in colour or unsightly in appearance are
rendered more pleasing to the eye and fetch a higher price.
Thausing claims that it is decidedly beneficial to subject hops to the
sulphuring process on the kiln ; but, unless where the mildew and
other parasitic diseases have made their appearance, sulphuring is
decidedly injurious as well as encourages fraud. On the other hand,
it seems to be a pretty general custom nowadays to sprinkle the hop
plants whilst growing with flowers of sulphur, to prevent or destroy
certain diseases which attack the plants at various stages of their
growth — such as mildew and blight — but it is evident that very
little of this is to be found on the hop cones after picking ; but even
if any should remain adherent, being present as free sulphur, it can
have little or no effect on the constituent principles of the hop. In
order to estimate the value of hops without having recourse to
analysis, the following physical features may be taken into
consideration : the fineness of the aroma, the proportion of lupulin
which the cones contain, the proportion of stalk, seeds, and
impurities which accompany the hops, and the geaeral appearance
of the cones themselves. The following experiments (J. Inst.
Brewing, xii. 301) were undertaken some years ago by the writer,
with a view to getting some definite idea of the action of the various
salts occurring in brewing waters upon hops. Both as regards the
extractive properties of these salts as well as the flavour and colour
of the extract so obtained, several experiments were made, of which
the mean value is given in the annexed table. The method of
experiment was as follows : The dry salts were added to distilled
water at the rate of 21 grains per gallon, or 0-3 gram per litre ; 10
grams of hops were then digested with 900 c.c. of each solution in a
boiling water- bath, for one hour, cooled down to ordinary
temperature, and made up to 1005 c.c. (10 grams of hops being
found to be equivalent in bulk to 5 c.c. of water), shaken well up
and filtered as bright as possible ; 100 c.c. contained the extract of 1
gram of hops. This quantity was evaporated to dryness, dried in
water - oven and weighed until constant, then ignited and weighed
again ; the latter weight subtracted from the former gave the weight
of organic matter extracted from 1 gram of hops (J. Inst. Brewing,
xii. 300). Analysis of colour XT Extract, Colour -S ;ini^ of salt per
cent. ID 4-inch cell. Total units Bed Yellow J? lavour Sodium chloride
18 7-2 1-2 6-0 Pleasant. Calcium chloride 17 6-7 1-2 4-6 it Sodium
sulphate 16 6-8 1-3 5-5 Rank. Potassium sulphate . 16 — — —
Harsh. Magnesium sulphate 16 6-2 1-2 5-0 Pleasant. Calcium
sulphate 17 6-5 1-5 5-0 >» Sodium carbonate . 19 10-9 1-9 9-0
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookname.com