Security Without Obscurity A Guide To Pki

Operations 2nd Edition 2nd Jeff Stapleton W Clay

Epstein download

https://ebookbell.com/product/security-without-obscurity-a-guide-
to-pki-operations-2nd-edition-2nd-jeff-stapleton-w-clay-
epstein-54822594

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Security Without Obscurity A Guide To Pki Operations Second Edition

Jeff Stapleton W Clay Epstein

https://ebookbell.com/product/security-without-obscurity-a-guide-to-
pki-operations-second-edition-jeff-stapleton-w-clay-epstein-56899436

Security Without Obscurity A Guide To Confidentiality Authentication

And Integrity Jj Stapleton

https://ebookbell.com/product/security-without-obscurity-a-guide-to-
confidentiality-authentication-and-integrity-jj-stapleton-4741060

Security Without Obscurity A Guide To Cryptographic Architectures

First Edition Jeff Stapleton

https://ebookbell.com/product/security-without-obscurity-a-guide-to-
cryptographic-architectures-first-edition-jeff-stapleton-9954462

Security Without Obscurity A Guide To Cryptographic Architectures 1st

Edition J J Stapleton

https://ebookbell.com/product/security-without-obscurity-a-guide-to-
cryptographic-architectures-1st-edition-j-j-stapleton-10433376
Security Without Obscurity Epstein W Clay Stapleton Jeffrey James

https://ebookbell.com/product/security-without-obscurity-epstein-w-
clay-stapleton-jeffrey-james-5393050

Security Without Weapons Rethinking Violence Nonviolent Action And

Civilian Protection 1st Edition M S Wallace

https://ebookbell.com/product/security-without-weapons-rethinking-
violence-nonviolent-action-and-civilian-protection-1st-edition-m-s-
wallace-36927306

The Quest For Security Protection Without Protectionism And The

Challenge Of Global Governance Joseph E Stiglitz Editor Mary Kaldor
Editor

https://ebookbell.com/product/the-quest-for-security-protection-
without-protectionism-and-the-challenge-of-global-governance-joseph-e-
stiglitz-editor-mary-kaldor-editor-51903290

Dynamic Collaboration How To Share Information Solve Problems And

Increase Productivity Without Compromising Security 1st Edition Ray
Schwemmer Rick Havrilla

https://ebookbell.com/product/dynamic-collaboration-how-to-share-
information-solve-problems-and-increase-productivity-without-
compromising-security-1st-edition-ray-schwemmer-rick-havrilla-51382322

Kill Without Shame Ares Security Alexandra Ivy Ivy Alexandra

https://ebookbell.com/product/kill-without-shame-ares-security-
alexandra-ivy-ivy-alexandra-22108172
 Security Without Obscurity

Public Key Infrastructure (PKI) is an operational ecosystem that employs key management, cryptography,
information technology (IT), information security (cybersecurity), policy and practices, legal matters
(law, regulatory, contractual, privacy), and business rules (processes and procedures). Aproperly managed
PKI requires all of these disparate disciplines to function together – coherently, efficiently, effectually,
and successfully. Clearly defined roles and responsibilities, separation of duties, documentation,
and communications are critical aspects for a successful operation. PKI is not just about certificates,
rather it can be the technical foundation for the elusive “crypto-agility,” which is the ability to manage
cryptographic transitions. The second quantum revolution has begun, quantum computers are coming,
and post-quantum cryptography (PQC) transitions will become PKI operation’s business as usual.

Jeff Stapleton is the author of the Security Without Obscurity five-book series (CRC Press). He has
over 30 years’ cybersecurity experience, including cryptography, key management, PKI, biometrics,
and authentication. Jeff has participated in developing dozens of ISO, ANSI, and X9 security
standards for the financial services industry. He has been an architect, assessor, auditor, author, and
subject matter expert. His 30-year career includes Citicorp, MasterCard, RSA Security, KPMG,
Innové, USAF Crypto Modernization Program Office, Cryptographic Assurance Services (CAS),
Bank of America, and Wells Fargo Bank. He has worked with most of the payment brands, including
MasterCard, Visa, American Express, and Discover. His areas of expertise include payment systems,
cryptography, PKI, PQC, key management, biometrics, IAM, privacy, and zero trust architecture
(ZTA). Jeff holds a Bachelor of Science and Master of Science degrees in computer science from
the University of Missouri. He was an instructor at Washington University (St. Louis) and was an
adjunct professor at the University of Texas at San Antonio (UTSA).

W. Clay Epstein currently operates a cybersecurity consulting company Steintech LLC, specializing
in Cybersecurity, Encryption Technologies, PKI, and Digital Certificates. He has international
experience developing and managing public key infrastructures primarily for the financial services
industry. Clay has worked as an independent Cybersecurity and PKI consultant for the past 11 years.
Previously, Clay was the VP and Technical Manager at Bank of America responsible for the Bank’s
global Public Key Infrastructure and Cryptography Engineering Group. Prior to Bank of America,
Clay was CIO and Head of Operations at Venafi, a certificate and encryption key management
company. Prior to Venafi, Clay was Senior Vice President of Product and Technology at Identrus, a
global identity management network based on PKI for international financial institutions. Previously,
Clay also served as Head of eCommerce Technologies for Australia and New Zealand Banking
Group (ANZ) and was the CTO for Digital Signature Trust Co. Clay holds a Bachelor of Science in
Computer Science degree from the University of Utah and a Master of Business Administration in
Management Information Systems degree from Westminster College.
Security Without Obscurity
A Guide to PKI Operations
Second Edition

Jeff Stapleton and W. Clay Epstein

Designed cover image: ©Shutterstock Images
Second edition published 2024
by CRC Press
2385 NW Executive Center Drive, Suite 320, Boca Raton FL 33431
and by CRC Press
4 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN
CRC Press is an imprint of Taylor & Francis Group, LLC
© 2024 Jeff Stapleton and W. Clay Epstein
First edition published by CRC Press 2021
Reasonable efforts have been made to publish reliable data and information, but the author and
publisher cannot assume responsibility for the validity of all materials or the consequences of their use.
The authors and publishers have attempted to trace the copyright holders of all material reproduced in
this publication and apologize to copyright holders if permission to publish in this form has not been
obtained. If any copyright material has not been acknowledged please write and let us know so we
may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced,
transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or
hereafter invented, including photocopying, microfilming, and recording, or in any information
storage or retrieval system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, access www.copyright.com
or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923,
978-750-8400. For works that are not available on CCC please contact [email protected]
Trademark notice: Product or corporate names may be trademarks or registered trademarks and are
used only for identification and explanation without intent to infringe.
ISBN: 978-1-032-54522-6 (hbk)
ISBN: 978-1-032-54525-7 (pbk)
ISBN: 978-1-003-42529-8 (ebk)
DOI: 10.1201/9781003425298
Typeset in Times New Roman
by Apex CoVantage, LLC
Contents
Preface ..............................................................................................................................................xi
Errata ............................................................................................................................................. xiii

Chapter 1 Introduction ..................................................................................................................1

1.1 About This Book ............................................................................................... 2
1.2 Security Basics ..................................................................................................5
1.3 Standards Organizations ................................................................................... 8
Notes........................................................................................................................... 12

Chapter 2 Cryptography Basics .................................................................................................. 14

2.1 Encryption ....................................................................................................... 16
2.2 Authentication ................................................................................................. 19
2.3 Nonrepudiation ................................................................................................ 24
2.4 Key Management ............................................................................................ 26
2.5 Cryptographic Modules .................................................................................. 34
2.5.1 Cryptographic Module Specification ................................................ 35
2.5.2 Cryptographic Module Interfaces ...................................................... 37
2.5.3 Roles, Services, and Authentication .................................................. 37
2.5.4 Software and Firmware Security ....................................................... 39
2.5.5 Operational Environment................................................................... 39
2.5.6 Physical Security ................................................................................ 41
2.5.7 Non-Invasive Security ....................................................................... 42
2.5.8 Sensitive Security Parameter Management ....................................... 42
2.5.9 Self-Tests ............................................................................................ 43
2.5.10 Life Cycle Assurance .........................................................................44
2.5.11 Mitigation of Other Attacks ...............................................................46
Notes........................................................................................................................... 47

Chapter 3 PKI Building Blocks .................................................................................................. 48

3.1 PKI Standards Organizations.......................................................................... 49
3.2 PKI Protocols: SSL and TLS .......................................................................... 62
3.2.1 TLS v1.2 Overview ............................................................................ 65
3.2.2 TLS v1.3 Overview ............................................................................ 70
3.3 PKI Protocol: IPsec ......................................................................................... 74
3.4 PKI Protocol: S/MIME ................................................................................... 74
3.5 PKI Methods: Legal Signatures ...................................................................... 75
3.6 PKI Methods: Code Sign................................................................................. 76
3.7 PKI Architectural Concepts ............................................................................ 76
Notes...........................................................................................................................81

Chapter 4 PKI Management and Security .................................................................................. 83

4.1 RFC 2527 Introduction.................................................................................... 89
4.1.1 RFC 3647 Overview .......................................................................... 89
v
vi Contents

4.1.2 RFC 3647 Document Name and Identification .................................94

4.1.3 RFC 3647 PKI Participants................................................................ 95
4.1.4 RFC 3647 Certificate Usage .............................................................. 96
4.1.5 RFC 3647 Policy Administration.......................................................97
4.1.6 RFC 3647 Definitions and Acronyms ............................................... 98
4.2 RFC 2527 Publication and Repository Responsibilities .................................99
4.2.1 RFC 3647 Repositories ......................................................................99
4.2.2 RFC 3647 Publication of Certification Information........................ 100
4.2.3 RFC 3647 Time or Frequency of Publication .................................. 100
4.2.4 RFC 3647 Access Controls on Repositories .................................... 101
4.3 RFC 2527 Identification and Authentication ................................................ 101
4.3.1 RFC 3647 Naming ........................................................................... 102
4.3.2 RFC 3647 Initial Identity Validation ............................................... 103
4.3.3 RFC 3647 Identification and Authentication for Rekey Requests ... 104
4.3.4 RFC 3647 Identification and Authentication for
Revocation Requests ........................................................................ 105
4.4 RFC 2527 Certificate Lifecycle Operational Requirements......................... 107
4.4.1 RFC 3647 Certificate Application ................................................... 108
4.4.2 RFC 3647 Certificate Application Processing ................................ 109
4.4.3 RFC 3647 Certificate Issuance ........................................................ 110
4.4.4 RFC 3647 Certificate Acceptance ................................................... 110
4.4.5 RFC 3647 Key Pair and Certificate Usage .......................................111
4.4.6 RFC 3647 Certificate Renewal ........................................................ 113
4.4.7 RFC 3647 Certificate Rekey .............................................................114
4.4.8 RFC 3647 Certificate Modification ..................................................114
4.4.9 RFC 3647 Certificate Revocation and Suspension...........................116
4.4.10 RFC 3647 Certificate Status Services ..............................................117
4.4.11 RFC 3647 End of Subscription .........................................................118
4.4.12 RFC 3647 Key Escrow and Recovery ............................................. 118
4.5 RFC 3647 Facility, Management, and Operational and Physical Controls ... 119
4.5.1 RFC 3647 Physical Security Controls ............................................. 119
4.5.2 RFC 3647 Procedural Controls ........................................................ 121
4.5.3 RFC 3647 §5.3 Personnel Security Controls ................................... 121
4.5.4 RFC 3647 Audit Logging Procedures ............................................. 122
4.5.5 RFC 3647 Records Archival ............................................................ 123
4.5.6 RFC 3647 Key Changeover ............................................................. 124
4.5.7 RFC 3647 Compromise and Disaster Recovery .............................. 125
4.5.8 RFC 3647 CA or RA Termination ................................................... 125
4.6 RFC 2527 Technical Security Controls ........................................................ 126
4.6.1 RFC 3647 Key Pair Generation and Installation ............................. 127
4.6.2 RFC 3647 Private Key Protection and Cryptographic
Module Controls............................................................................... 127
4.6.3 RFC 3647 Other Aspects of Key Pair Management ........................ 128
4.6.4 RFC 3647 Activation Data ............................................................... 129
4.6.5 RFC 3647 Computer Security Controls ........................................... 130
4.6.6 RFC 3647 Life Cycle Security Controls .......................................... 130
4.6.7 RFC 3647 Network Security Controls ............................................. 131
4.6.8 RFC 3647 Time Stamping ............................................................... 131
4.7 RFC 2527 Certificate, CRL, and OCSP Profiles .......................................... 132
4.7.1 RFC 3647 Certificate Profile ........................................................... 132
4.7.2 RFC 3647 CRL Profile .................................................................... 133
Contents vii

4.7.3 RFC 3647 OCSP Profile .................................................................. 134

4.7.4 Other PKI-Related Profiles .............................................................. 134
4.8 RFC 2527 Compliance Audits and Other Assessments ................................ 134
4.8.1 RFC 3647 Frequency or Circumstances .......................................... 135
4.8.2 RFC 3647 Identity/Qualifications of Assessor ................................ 135
4.8.3 RFC 3647 Assessor’s Relationship to Assessed Entity ................... 135
4.8.4 RFC 3647 Topics Covered by Assessment ...................................... 136
4.8.5 RFC 3647 Actions Taken as a Result of Deficiency........................ 136
4.8.6 RFC 3647 Communication of Results ............................................. 136
4.9 RFC 2527 Other Business and Legal Matters .............................................. 136
4.9.1 RFC 3647 Fees ................................................................................. 137
4.9.2 RFC 3647 Financial Responsibility ................................................. 137
4.9.3 RFC 3647 Confidentiality of Business Information........................ 137
4.9.4 RFC 3647 Privacy of Personal Information .................................... 137
4.9.5 RFC 3647 Intellectual Property Rights ........................................... 137
4.9.6 RFC 3647 Representations and Warranties..................................... 138
4.9.7 RFC 3647 Disclaimers of Warranties .............................................. 138
4.9.8 RFC 3647 Limitations of Liability................................................... 138
4.9.9 RFC 3647 Indemnities ..................................................................... 138
4.9.10 RFC 3647 Term and Termination .................................................... 138
4.9.11 RFC 3647 Individual Notices and Communications with
Participants ....................................................................................... 138
4.9.12 RFC 3647 Amendments ................................................................... 139
4.9.13 RFC 3647 Dispute Resolution Procedures ...................................... 139
4.9.14 RFC 3647 Governing Law ............................................................... 139
4.9.15 RFC 3647 Compliance with Applicable Law .................................. 140
4.9.16 RFC 3647 Miscellaneous Provisions ............................................... 140
4.9.17 RFC 3647 Other Provisions ............................................................. 140
Notes......................................................................................................................... 140

Chapter 5 PKI Roles and Responsibilities ................................................................................ 141

5.1 Certificate Authority ..................................................................................... 142
5.1.1 Root CA ............................................................................................ 142
5.1.2 Subordinate CA ................................................................................ 144
5.1.3 OCSP Systems ................................................................................. 146
5.2 Registration Authority................................................................................... 147
5.3 Policy Authority ............................................................................................ 148
5.4 Subscribers .................................................................................................... 149
5.5 Relying Party................................................................................................. 150
5.6 Agreements.................................................................................................... 151
5.6.1 Certificate Authority Agreements ................................................... 151
5.6.2 Registration Authority Agreements................................................. 154
5.6.3 Subscriber Agreements .................................................................... 154
5.6.4 Relying Party Agreements ............................................................... 154
Note .......................................................................................................................... 154

Chapter 6 Security Considerations ........................................................................................... 155

6.1 Physical Security ........................................................................................... 156
6.2 Logical Security ............................................................................................ 162
viii Contents

6.3 Audit Logs ..................................................................................................... 170

6.4 Cryptographic Modules ................................................................................ 173
Notes.........................................................................................................................175

Chapter 7 Operational Considerations ..................................................................................... 177

7.1 CA Architectures........................................................................................... 179
7.2 Security Architectures .................................................................................. 186
7.3 Certificate Management................................................................................ 188
7.4 Business Continuity ...................................................................................... 190
7.5 Disaster Recovery ......................................................................................... 193
7.6 Affiliations .................................................................................................... 196
7.7 Crypto-Agility ............................................................................................... 197
7.8 Cloud PKI ...................................................................................................... 198
Notes.........................................................................................................................199

Chapter 8 Incident Management............................................................................................... 201

8.1 Areas of Compromise in a PKI ..................................................................... 201
8.1.1 Offline Root CA............................................................................... 202
8.1.2 Online Intermediate CA With Issuing CAs ..................................... 202
8.1.3 Online Issuing CA............................................................................ 203
8.1.4 Online RA ........................................................................................ 203
8.1.5 Online CRL Service.........................................................................204
8.1.6 Online OCSP Service.......................................................................204
8.1.7 End User’s Machine .........................................................................204
8.2 PKI Incident Attack Actions .........................................................................204
8.2.1 Private Key Compromise .................................................................206
8.2.2 Private Key Access .......................................................................... 207
8.2.3 Limited Access to the Private Key .................................................. 207
8.2.4 Other Attacks ................................................................................... 207
8.3 PKI Incident Response Plan .......................................................................... 208
8.4 Monitoring the PKI Environment Prior to an Incident................................. 210
8.5 Initial Response to an Incident...................................................................... 212
8.6 Detailed Discovery of an Incident ................................................................ 214
8.7 Collection of Forensic Evidence.................................................................... 215
8.8 Reporting of an Incident ............................................................................... 216
Notes......................................................................................................................... 217

Chapter 9 PKI Governance, Risk, and Compliance ................................................................. 219

9.1 PKI Governance ............................................................................................ 219
9.1.1 Management Organization............................................................... 220
9.1.2 Security Organization ...................................................................... 222
9.1.3 Audit Organization........................................................................... 224
9.2 PKI Risks....................................................................................................... 226
9.3 Cryptography Risks ...................................................................................... 226
9.3.1 Algorithm Issues .............................................................................. 228
9.3.2 Protocol Issues ................................................................................. 229
9.3.3 Product Issues .................................................................................. 231
9.4 Cybersecurity Risks ...................................................................................... 231
Contents ix

9.5 Operational Risks .......................................................................................... 234

9.5.1 Monitoring ....................................................................................... 234
9.5.2 Capacity............................................................................................ 235
9.5.3 Continuity......................................................................................... 236
9.5.4 Resources ......................................................................................... 236
9.5.5 Knowledge ....................................................................................... 236
9.6 PKI Compliance ............................................................................................ 237
9.6.1 Evaluation Criteria ........................................................................... 238
9.6.2 Gap Assessment ............................................................................... 241
9.6.3 Audit Process ................................................................................... 243
9.7 PKI Risk Assessment .................................................................................... 245
9.8 PKI Cloud Assessment.................................................................................. 248
Notes......................................................................................................................... 248

Chapter 10 PKI Industry............................................................................................................. 250

10.1 ITU-T X.509 .................................................................................................. 251
10.2 EMV Integrated Circuit Card (ICC) ............................................................. 252
10.3 ASC X9 PKI Standards................................................................................. 254
10.4 Secure Electronic Transactions (SET) .......................................................... 258
10.5 Secure Socket Layer (SSL) ............................................................................ 260
10.6 PKI Forum ..................................................................................................... 261
10.7 American Bar Association (ABA) ................................................................ 262
10.8 WebTrust CA .................................................................................................264
10.9 CA Browser Forum ....................................................................................... 266
10.10 Cloud Security Alliance (CSA) ..................................................................... 267
10.11 NIST PQC Program ...................................................................................... 272
10.12 ASC X9 Financial PKI .................................................................................. 275
10.12.1 X9 Financial PKI Origins ................................................................ 275
10.12.2 PKI Architecture Models ................................................................. 276
10.12.3 X9 Financial PKI Program ..............................................................284
Notes......................................................................................................................... 285

Bibliography................................................................................................................................. 287
B.1 ASC X9 Financial Services........................................................................... 287
B.2 European Telecommunication Standards Institute (ETSI) ........................... 288
B.3 Internet Engineering Task Force (IETF) ...................................................... 288
B.4 International Organization for Standardization (ISO) .................................. 290
B.5 National Institutes of Standards and Technology (NIST) ............................ 292
B.6 Public Key Cryptography Standards (PKCS) ............................................... 294
B.7 Miscellaneous ................................................................................................ 294
Index.............................................................................................................................................. 297
Preface
Most of the books on public key infrastructure (PKI) seem to focus on asymmetric cryptography,
X.509 certificates, certificate authority (CA) hierarchies, or certificate policy (CP), and certificate
practice statements (CPS). While algorithms, certificates, and theoretical policies and practices are
all excellent discussions, the real-world issues for operating a commercial or private CA can be
overwhelming. Pragmatically, a PKI is an operational system that employs asymmetric cryptogra­
phy, information technology, operating rules, physical and logical security, and legal matters. Much
like any technology, cryptography, in general, undergoes changes: sometimes evolutionary, some­
times dramatically, and sometimes unknowingly. Any of these can cause a major impact, which can
have an adverse effect on a PKI’s operational stability. Business requirements can also change such
that old rules must evolve to newer rules, or current rules must devolve to address legal issues such
as lawsuits, regulatory amendments, or contractual relationships. This book provides a no-nonsense
approach and realistic guide for operating a PKI system.
In addition to discussions on PKI best practices, this book also contains warnings against PKI
bad practices. Scattered throughout the book are anonymous case studies identifying good or bad
practices. These highlighted bad practices are based on real-world scenarios from the authors’ expe­
riences. Often bad things are done with good intentions but cause bigger problems than the original
one being solved.
As with most new technologies, PKI has survived its period of inflated expectations, struggled
through its disappointment phase, and eventually gained widespread industry adoption. Today, PKI,
as a cryptographic technology, is embedded in hardware, firmware, and software throughout an
enterprise in almost every infrastructure or application environment. However, it now struggles with
apathetic mismanagement and new vulnerabilities. Moore’s law continues to erode cryptographic
strengths, and, in response, keys continue to get larger and protocols get more complicated. Fur­
thermore, attackers are becoming more sophisticated, poking holes in cryptographic protocols,
which demands continual reassessments and improvements. Consequently, managing PKI systems
has become problematic. The authors offer a combined knowledge of over 50 years in develop­
ing PKI-related policies, standards, practices, procedures, and audits with in-depth experience in
designing and operating various commercial and private PKI systems.

xi
Errata
Our sincere thanks to readers who spotted a few errors in previous books, and recognitions to our
reviewers for this book: Ralph S. Poore, Bill Poletti, and Richard M. Borden. Also, special appreci­
ation to Ralph, who has steadfastly reviewed multiple drafts of every book and provided excellent
comments, not only the mundane typos and punctuation but far more importantly brilliant discourse
on a wide variety of information security topics including my favorites: cryptography and key man­
agement. Without him, there would be far more errors.

SECURITY WITHOUT OBSCURITY: A GUIDE TO CONFIDENTIALITY, AUTHEN­

TICATION, AND INTEGRITY
• As far as we know, no errors have been reported.

SECURITY WITHOUT OBSCURITY: A GUIDE TO PKI OPERATIONS

• Saliha Lallali e-mailed me on March 17, 2017: I’m reading your book Security Without
Obscurity: A Guide to PKI Operations, and on page 28 I think there is a small mistake:
“the receiver uses the sender’s public key to verify the signature versus its own public key
to decrypt the data.” Good spotting, it should read: the receiver uses the sender’s public
key to verify the signature versus its own public key to encrypt the data.
• Note this error has been corrected in this Second Edition.

Security Without obScurity: A Guide to cryptoGrAphic ArchitectureS

• In the Annex: XOR Quick Reference there are a few errors in Table 2.1:
• The correct result is: 5 (0101) XOR 9 (1001) = C (1100)
• The correct result is: 5 (0101) XOR C (1100) = 9 (1001)
• The correct result is: 9 (1001) XOR A (1010) = 3 (0011)

Security Without obScurity: Frequently ASked queStionS (FAq)

• As far as we know, no errors have been reported.

Hopefully, there are no errors in this book: A Guide to PKI Operations, Second Edition

xiii
 1 Introduction

Public key infrastructure (PKI) is an operational system that employs key management, cryptog­
raphy, information technology (IT), information security (cybersecurity), legal matters, and busi­
ness rules as shown in the Venn diagram in Figure 1.1 called PKI Cryptonomics.1 While certainly
there are business, legal, security, technology, and cryptography areas within any organization that
function outside of a PKI, the fact is that a properly managed PKI requires all of these disparate
disciplines to function effectively. The lack of one or more of these factors can undermine a PKI’s
effectiveness and efficiency. Furthermore, all of these disciplines must interact and complement
each other within a PKI framework.
Cryptography includes asymmetric and symmetric encryption algorithms, digital signature algo­
rithms, hash algorithms, key lifecycle management controls, cryptographic modules, and security
protocols. Asymmetric cryptography provides digital signatures, encryption, and key management
capabilities to establish symmetric keys. Symmetric cryptography provides legacy key manage­
ment, encryption, and Message Authentication Codes (MAC). Legacy key management suffers
from a fundamental problem of how to securely establish an initial key that asymmetric cryptog­
raphy overcomes. Hash algorithms enable keyed Hash MAC (HMAC) and digital signatures. Key
lifecycle management includes generation, distribution, installation, usage, backup and recovery,
expiration, revocation, termination, and archive phases. Cryptographic modules include software
libraries and specialized hardware. Security protocols establish cryptographic keys and enable data
protection schemes.
IT involves mainframes, midrange, personal computers, mobile devices, local area networks,
wide area networks, the Internet, applications, browsers, operating systems, and network devices.
Application server platforms include hardware, firmware, operating systems, and software applica­
tions. End-user platforms include hardware, firmware, operating systems, applications, browsers,
widgets, and applets. Networks include switches, routers, firewalls, network appliances, and net­
work protocols.
Information security, also called cybersecurity, involves entity identification, authentication,
authorization, accountability, access controls, activity monitoring, event logging, information ana­
lytics, incident response, and security forensics. Logging tracks event information such as who,
what, where, when, how, and hopefully why. Many aspects of security rely on cryptography and key
management for data confidentiality, data integrity, and data authenticity. For details, refer to the
book Security Without Obscurity: A Guide to Confidentiality, Integrity, and Authentication [B.7.2].
Legal matters address privacy, intellectual property, representations, warranties, disclaimers,
liabilities, indemnities, terms, termination, notices, dispute resolution, national and international
governing law, and compliance. While many of these issues may be incorporated into the CPS or
related agreements such as the CSA or RPA for public consumption, others might be addressed in
separate documents such as contractual master agreements, statements of work, or an organization’s
standard terms and conditions. The application environments, third-party business relationships,
and geopolitical locations often influence the various legal implications.

FIGURE 1.1 PKI cryptonomics.

DOI: 10.1201/9781003425298-1 1
2 Security Without Obscurity

Business rules involve roles and responsibilities for the registration authority (RA), the cer­
tificate authority (CA), subscribers (also known as key owners), relying parties, applications,
fees, revenues, risk management, and fraud prevention. RA services include certificate requests,
revocation requests, and status queries. CA services include certificate issuance, certificate revo­
cation list (CRL) issuance, and Online Certificate Status Protocol (OCSP) updates. The CA busi­
ness rules are defined in a variety of documents including a certificate practice statement (CPS),
certificate subscriber agreement (CSA), and relying party agreement (RPA). Furthermore, the
CA will typically provide some documents for public consumption, some proprietary with dis­
closure under a nondisclosure agreement (NDA) or contract, while others are confidential for
internal use only.
PKI is also a subset of the broader field of cryptography, which in turn is a subset of general
mathematics, also shown in Figure 1.1. Cryptography has its own unique set of risks, rules, and
mathematics based on number theory, which essentially creates its own set of operating laws, and so
can be called cryptonomics. PKI Cryptonomics incurs growth as more applications, cloud services,
and microservices are available online, including mobile apps and Internet of Things (IoT), incor­
porating cryptography. Cryptonomics also suffers from a type of inflation as Moore’s law continues
to increase computational and storage capabilities [B.7.1]. NIST describes “cryptographic strength”
as the amount of work either to break a cryptographic algorithm or to determine a key, which
is expressed as the number of bits relative to the key size [B.5.19]. Simplistically, as computers
get faster, keys must get larger. Cryptonomics further demonstrate lifecycle differences for various
symmetric, asymmetric, and now post-quantum cryptography (PQC) algorithms. Accordingly, PKI
Cryptonomics embodies all of the general cryptography characteristics and the additional manage­
rial traits and issues from IT, business, and legal domains.
For the purposes of this book, cryptographic agility (Crypto-Agility) is defined as the capability
of a PKI to easily switch between cryptographic algorithms, encryption key strengths, and certifi­
cate contents in response to changing system and enterprise needs. See Section 7.7 “Crypto-Agil­
ity,” for details.
The X9.24–2 [B.1.2] defines Crypto-Agility as “a practice used to ensure a rapid response to a
cryptographic threat. The goal of Crypto-Agility is to adapt to an alternative cryptographic standard
quickly without making any major changes to infrastructure.”
This is a good working definition that has a focus on a PKI’s “infrastructure.” The PKI infra­
structure is an important part but not the only part of an overall PKI operation. Other important
components of Crypto-Agility include the PMA’s approval process and Legal’s input as critical
components of the PKI. Another essential component includes the risk analysis of any changes that
a new cryptographic algorithm may have. All of these components and the responsive infrastructure
are required for a PKI to operate in a crypto-agile environment.
Also, for this book, a Cloud PKI is defined as either the migration of a PKI-enabled application
or the relocation of the PKI itself to a cloud environment. See Section 7.8 “Cloud PKI,” for further
discussion. Note that a Cloud PKI can be operated with in-house resources or in conjunction with
cloud provider resources.
This book provides realistic guidelines for operating and managing PKI systems, including pol­
icy, standards, practices, and procedures. Various PKI roles and responsibilities are identified, secu­
rity and operational considerations are discussed, incident management is reviewed, and aspects of
governance, compliance, and risks (GCR) are presented. This book also both discusses PKI best
practices and provides warnings against PKI bad practices based on anonymous real-world exam­
ples drawn from the authors’ personal experiences.

1.1 ABOUT THIS BOOK

While most books on cryptography tend to focus on algorithms, and PKI books discuss certificates,
this book addresses governance, risk, and compliance issues of PKI systems for issuers, subjects,
Introduction 3

and relying parties. The scope of this book includes both X.509 certificates and other PKI cre­
dentials, as well as various certificate authority (CA) and registration authority (RA) hierarchies,
including pyramid architectures, hub and spoke topologies, bridge models, and cross-certification
schemes. Furthermore, this book addresses PKI policy, standards, practices, and procedures, includ­
ing certificate policy and certificate practice statements (CP and CPSs).
The intended audience for this book includes technicians, administrators, managers, auditors,
corporate lawyers, security professionals, and senior-level management, including chief information
officers (CIOs), chief technology officers (CTOs), and chief information security officers (CISOs).
Each of these roles can benefit from this book in a variety of ways. A common benefit to the reader
is general education and awareness of PKI systems, cryptography, and key management issues.

• Senior managers are responsible for making strategic decisions and supervising manag­
ers. The more senior managers know about the underlying technologies supported by their
subordinate managers and their respective teams, the better they can manage the overall
business. Making unknowledgeable strategic decisions is a bad practice that can adversely
affect staffing, systems, and profitability.
• Managers are responsible for making tactical decisions and supervising personnel includ­
ing technicians, administrators, auditors, and security professionals. The more managers
know about the underlying technologies supported by their teams, the better they can
manage their staff. Making unknowledgeable tactical decisions is a bad practice that can
adversely affect staffing, systems, and productivity.
• Administrators are responsible for installing, configuring, running, monitoring, and
eventually decommissioning network or system components inclusive of hardware
devices, firmware modules, and software elements. Extensive knowledge of PKI systems
is needed by administrators to properly manage cryptographic features, functionality, and
associated cryptographic keys.
• Auditors are responsible for verifying compliance to information and security policy,
standards, practices, and procedures. Risk can be better identified and managed when the
evaluator has a solid understanding of general cryptography, specifically PKI, and related
key management. Furthermore, compliance includes not just the organization’s internal
security requirements but also external influences such as regulations, international and
national laws, and contractual responsibilities.
• Security professionals are responsible for assisting other teams and developing security
policy, standards, practices, and procedures. However, security professionals are expected
to have an overall knowledge base with expertise typically in only a few areas, so this
book can be used as a reference guide and refresher material. For example, the (ISC)2
CISSP® program is organized into eight domains with cryptography included in one of
them, cryptography and key management is no longer its own domain area, and further
the CISSP certification only requires emphasis in two of the domains.
• Corporate lawyers are responsible for legal practices and interpretations within an organi­
zation. Consequently, having a basic understanding of PKI enhances their ability to advise
on warranty claims, disclaimers, limitations, liabilities, and indemnifications associated
with the issuance and reliance of public key certificates.
• Subscribers are responsible for protecting their cryptographic keys and using them prop­
erly in accordance with CA and RA policies, standards, practices, agreements, and pro­
cedures. Accordingly, having both a fundamental understanding of all PKI roles and
responsibilities and specific awareness of the subscriber duties is important.
• Relying parties are responsible for validating and using digital certificates and their cor­
responding certificate chain in accordance with CA policy, standards, practices, agree­
ments, and procedures. Hence, having both a fundamental understanding of all PKI roles
and responsibilities and knowledge of the relying party obligations is paramount.
4 Security Without Obscurity

In addition to operational responsibilities, senior managers and managers need to address risk
and compliance issues. Compliance might focus primarily on regulatory or other federal, state, or
local laws, but contractual obligations must also be addressed. Relative risks also need to be evalu­
ated for determining acceptable losses due to fraud, identity theft, data theft, potential legal actions,
or other cost factors. Risks might be detectable or preventable, compensating controls might help
mitigate issues, or backend controls might lessen the overall impacts.
The chapters in this book are organized as a learning course and as a reference guide. As
a learning course approach, each chapter builds on the information provided in the previous
chapters. The reader can progress from chapter to chapter to build their PKI knowledge. From
a reference guide perspective, the chapters are structured by major topics for easy lookup and
refresher material.

• Chapter 1, “Introduction,” provides an overview of the book and introduces security basics
and associated standards organizations as background for Chapter 2, “Cryptography
Basics,” and Chapter 3, “PKI Building Blocks.”
• Chapter 2, “Cryptography Basics,” provides details on symmetric and asymmetric cryp­
tographic solutions for encryption, authentication, nonrepudiation, and cryptographic
modules. The cryptography details establish connections between the associated security
areas for confidentiality, integrity and authentication, and nonrepudiation.
• Chapter 3, “PKI Building Blocks,” builds on the general cryptography basics provided
in Chapter 2, “Cryptography Basics,” providing details of PKI standards, protocols, and
architectural components. The PKI building blocks provide a knowledge base for the
remainder of the chapters.
• Chapter 4, “PKI Management and Security,” builds on the information provided in
Chapter 3, “PKI Building Blocks,” to establish the groundwork for documenting and man­
aging the PKI system and application components. The methodology is organized in a
top–down approach, beginning with policy, then practices, and finally procedures.
• Chapter 5, “PKI Roles and Responsibilities,” identifies the various PKI roles and corre­
sponding responsibilities including positions, functions, jobs, tasks, and applications. The
information presented in this chapter provides a reference baseline used in subsequent
chapters.
• Chapter 6, “Security Considerations,” discusses various security considerations that
affect the operational environments of the CA, the RA, the subscriber, and the relying
party. Subscribers and relying parties include individuals using workstation applications
or server applications running on midrange or mainframe platforms.
• Chapter 7, “Operational Considerations,” discusses operational issues for PKI roles iden­
tified in Chapter 5, “PKI Roles and Responsibilities,” balanced against security issues
described in Chapter 6, “Security Considerations.”
• Chapter 8, “Incident Management,” discusses various types of events and methodolo­
gies for handling atypical or unusual occurrences that have security or PKI operational
implications. Incidents can originate from insider threats or external attacks, system or
application misconfigurations, software or hardware failures, zero-day faults, and other
vulnerabilities. Components of incident management include monitoring, response, dis­
covery, reporting, and remediation.
• Chapter 9, “PKI Governance, Risk, and Compliance,” addresses organizational issues such
as management support, security completeness, and audit independence. Management
support includes the policy authority for managing the CP and CPS, facility and environ­
mental controls, asset inventory, application development, system administration, vendor
relationships, business continuity, and disaster recovery. Security completeness includes
planning and execution, data classification, personnel reviews, physical controls, cyberse­
curity, incident response, access controls, monitoring, and event logs. Audit independence
Introduction 5

includes assessments, evaluations, and reviews that are reported to senior management
without undue influence from operational teams.
• Chapter 10, “PKI Industry,” provides an overview of the industry including standards and
groups that manage or influence PKI operations, with special attention on the Financial
PKI.

The remainder of this chapter introduces security disciplines (i.e., confidentiality, integrity,
authentication, authorization, accountability, nonrepudiation) and provides background on vari­
ous standards organizations (e.g., ANSI, ISO, NIST) and related information security standards
focusing on cryptography and PKI. These discussions establish connections with symmetric and
asymmetric cryptographic methods and the associated standards referenced throughout the book,
in particular Chapter 3, “PKI Building Blocks,” along with a historical perspective of cryptography
and PKI referenced throughout the book.

1.2 SECURITY BASICS

Most security practitioners are familiar with the basic security tenets of confidentiality, integrity,
authentication, and nonrepudiation. In addition to authentication, authorization and accountability
are also important, and the three are sometimes referred to as the “AAA” security controls. The
book Security Without Obscurity: A Guide to Confidentiality, Integrity, and Authentication [B.7.2]
includes authorization and accountability as part of authentication, but for the purposes of this book,
we separate and offer the following basic definitions of security:

• Confidentiality is the set of security controls to protect data from unauthorized access
when in transit, process, or storage. Transit occurs when data is transmitted between two
points. Process occurs when data is resident in the memory of a device. Storage occurs
when data is stored on stationary or removable media. Note that the states of transit, pro­
cess, and storage align with the PCI Data Security Standard (DSS)2 for cardholder data.
• Integrity is the set of security controls to protect data from undetected modification or
substitution when in transit or storage. Data in process is a necessary unstable state where
data is being intentionally changed; however, this is where software assurance plays an
important role.
• Authentication is the set of security controls to verify an entity and potentially grant
access to system resources, including data and applications. There is a distinction between
regular data and authentication data, also called authentication credentials. Authorization
and accountability are sometimes included as part of authentication controls, but for the
purposes of this book we treat all three of these security areas as separate controls.
• Authorization is the set of security controls to validate permissions for accessing system
or network resources to read or write data, or to read, write, or execute software. Such
approvals are based on authentication occurring first to verify the requestor, followed by
authorization to validate that the requestor is allowed access.
• Accountability is the set of controls to monitor and analyze the three “W” facts: who did
what and when they did it. This includes log management for generating, collecting, stor­
ing, examining, alerting, and reporting events.
• Nonrepudiation is the set of security controls to prevent refusal by one party to acknowl­
edge an agreement or action claimed by another party. This is accomplished by having
both data integrity and authenticity provable to an independent third party.

Confidentiality can only be partially achieved using access controls. System administrators can
restrict access to files (data in storage) and systems (data in process), and under certain condi­
tions limit access to network components (data in transit). Files or memory might contain system
6 Security Without Obscurity

configurations, cryptographic parameters, or application data. However, only encryption can pro­
vide confidentiality for data in transit between communication nodes. Additionally, encryption can
also offer confidentiality for data in storage and in some cases even data in process. Because of
the role data encryption keys play in providing confidentiality data, encryption keys must also be
protected from disclosure or unauthorized access; otherwise, if the key is compromised, then the
encrypted data must be viewed as similarly compromised.
Integrity can be achieved using various comparison methods between what is expected (or sent)
versus what is retrieved (or received). Typically, integrity is validated using an integrity check value
(ICV), which might be derived cryptographically or otherwise. In general, the ICV is calculated
when a file is about to be written or a message is about to be sent, and it is verified when the file
is read or the message is received. If the previous (written or sent) ICV does not match the current
(read or received) ICV, then the file (or the ICV) has been modified or substituted and is untrustwor­
thy. However, a noncryptographic ICV can be recalculated disguising the attack, whereas the use of
a cryptographic key to generate and validate the ICV deters the attacker, who must first obtain the
cryptographic key in order to recalculate a valid ICV for the changed file or message.
Authentication methods for individuals and devices differ. Individual authentication methods
include the three basic techniques of something you know (called knowledge factors), something
you have (possession factors), and something you are (biometrics), and arguably a fourth method,
something you control (cryptographic keys), often included as a possession factor. Conversely,
device authentication can only use possession or cryptography factors, as devices cannot “remem­
ber” passwords or demonstrate biological characteristics. Some hardware devices have unique
magnetic, electromechanical, or electromagnetic characteristics that can be used for recognition.
Regardless, once an entity has been authenticated and its identity has been verified, the associated
permissions are used to determine its authorization status. Furthermore, logs are generated by vari­
ous network appliances, system components, and application software for accountability.
All the authentication methods have the prerequisite that an initial authentication must be
achieved before the authentication credential can be established. The individual or device must be
identified to an acceptable level of assurance before a password can be set, a physical token can be
issued, a person can be enrolled into a biometric system, or a cryptographic key can be exchanged.
If the wrong entity is initially registered, then all subsequent authentications become invalid. Sim­
ilarly, if a digital certificate is issued to the wrong entity, then all succeeding authentications are
based on a false assumption. Thus, if “Alice” registers as “Bob” or if Bob’s authentication creden­
tial is stolen or his identity covertly reassigned to Alice’s authentication credential, then basically
“Alice” becomes “Bob,” resulting in a false-positive authentication.
Nonrepudiation methods are a combination of cryptographic, operational, business, and legal
processes. Cryptographic techniques include controlling keys over the management lifecycle.
Operational procedures include information security controls over personnel and system resources.
Business rules include roles and responsibilities, regulatory requirements, and service agreements
between participating parties. Legal considerations include warranties, liabilities, dispute resolu­
tion, and evidentiary rules for testimony and expert witnesses.
For more details on confidentiality, integrity, authentication, and nonrepudiation, refer to the
book Security Without Obscurity: A Guide to Confidentiality, Integrity, and Authentication [B.7.2].
The book organizes security controls into three major areas, confidentiality, integrity, and authen­
tication, which were chosen as the primary categories to discuss information security. While data
confidentiality and integrity are fundamental information security controls, other controls such
as authentication, authorization, and accountability (AAA) are equally important. The book also
addresses nonrepudiation and privacy to help round out the overall discussion of information secu­
rity controls. And since cryptography is used in almost every information security control such as
data encryption, message authentication, or digital signatures, the book dedicates an entire chapter
to key management, one of the most important controls for any information security program and
unfortunately one of the most overlooked areas.
Introduction 7

FIGURE 1.2 Selected history of cryptography.

PKI incorporates both symmetric and asymmetric cryptography along with many other security
controls. Symmetric cryptography includes data encryption, message integrity and authentication,
and key management. Asymmetric cryptography includes data encryption, message integrity and
authentication, nonrepudiation, and key management. Asymmetric key management is often used
to establish symmetric keys. However, symmetric cryptography has been around for a long while,
whereas asymmetric cryptography is rather recent. Figure 1.2 shows a comparison between the his­
tory of symmetric and asymmetric cryptography.
In the known history of the world, cryptography has been around for at least 4,000 years begin­
ning with the substitution of hieroglyphics by the Egyptian priesthood to convey secret messages
[B.7.3]. The top arrow shows the 4,000-year history of symmetric cryptography. Interestingly, the
earliest known human writings are Sumerian pictograms and cuneiform in Mesopotamia, which
are only a thousand years older than cryptography. Substitutions ciphers are a form of symmetric
cryptography since the mapping between cleartext and ciphertext characters represents the sym­
metric key. For example, a simple substitution cipher maps the English alphabet of 26 letters to the
numbers 1–26, and the key would be the relative position of each letter, for example, A is 1, B is 2,
and so on.
Better-known symmetric algorithms include the Caesar cipher,3 used by Julius Caesar in Rome;
the Jefferson wheel,4 designed by Thomas Jefferson but still used as late as World War I; and the
infamous German Enigma machine,5 ultimately defeated by the Allies of World War II. Further­
more, World War II ushered in modern cryptography, which today includes symmetric algorithms
(e.g., DES, RC4, and AES) and asymmetric algorithms (e.g., DH, RSA, and ECC).
In comparison to symmetric ciphers, asymmetric cryptography has only been around since the
1970s depicted by the short bottom arrow showing its short 50-year history. So, in comparison,
symmetric cryptography has been around for thousands of years whereas asymmetric cryptography
has only been around for decades.
In order for the wide variety of symmetric and asymmetric algorithms to be properly imple­
mented, and for the two cryptography disciplines to properly interoperate within secure protocols,
applications, and business environments, standardization is necessary. Standards can provide con­
sistency and continuity across product lines, among vendors, and for intra- or inter-industry seg­
ments. Many different participants rely on standards.

• Developers and manufacturers rely on standards to build secure software, firmware, and
hardware products.
• Implementers and service providers rely on standards for products and protocols to
securely interoperate.
• Managers and administrators rely on the underlying standards to safely operate applica­
tions and systems that incorporate cryptographic solutions.
8 Security Without Obscurity

• Auditors and security professionals expect applications to execute properly and to be man­
aged properly according to industry standards.

Standards are a big part of security, cryptography, and consequently PKI Cryptonomics so before
delving deeper into cryptography, a basic understanding of the standards organizations and the
standardization process will help. The next section provides a selected overview of PKI-related
standards and the organizations that are accredited to develop industry standards.

1.3 STANDARDS ORGANIZATIONS

Standards publication and the standardization development process are accomplished by standards
organizations. Some standards development groups are formally recognized internationally, some
are formal national groups, while others are self-recognized or more informal groups. Figure 1.3
provides an overview of informal, formal international, and formal U.S. national standards organi­
zations. There are several international formal groups, notably ISO6 (pronounced “eye-so,” derived
from the Greek prefix isos, meaning equal), which was established in 1946 by delegates from 25
countries. The United States is one of the 164 country members of ISO, whose mandatory national
standards body is the American National Standards Institute (ANSI†). ANSI does not develop stand­
ards; rather, it accredits standards developers within industry segments and designates technical
advisory group (TAG) to international groups.

• INCITS – For example, the International Committee for Information Technology

Standards7 (INCITS), originally named “X3,” is an ANSI-accredited standards devel­
oper organization (SDO) for the Information and Communications Technologies (ICT)
industry. INCITS is also the designated U.S. TAG to the Joint Technical Committee
1 (JTC1), which is the international standards developer for ICT established mutu­
ally by ISO and the International Electrotechnical Commission (IEC). Within JTC1 is
Subcommittee 27 for Information Security (SC27), which has Cyber Security (CS1) as
its U.S. TAG. INCITS standards are labeled and numbered using either INCITS or its
original name X3.
• ASC X9 – Another example is the Accredited Standards Committee X98 (ASC X9) for the
financial services industry, which retained its original “X9” name. In addition to being the
U.S. TAG to Technical Committee 68 Financial Services, X9 is also the TC68 Secretariat.
Within TC68 is Subcommittee 2 for Information Security (SC2), which has the X9F Data
and Information Security Subcommittee as its U.S. TAG. X9 standards are labeled and
numbered using its X9 name, for example, X9.79 versus ISO 21188.

FIGURE 1.3 Standards organizations.

Introduction 9

From an international perspective, JTC1/SC27 and TC68/SC2 maintain a liaison relationship,

sharing information but developing separate and independent standards. TC68 standards are labeled
and numbered as ISO, whereas JTC1 standards are labeled ISO/IEC and numbered accordingly.
Domestically within the United States, both INCITS and X9 memberships are managed at the com­
pany level, but the groups do not share a similar relationship status beyond having some of the same
members. INCITS and X9 standards are accredited and therefore are ANSI standards.

• TC68 – One of the many groups within ISO is Technical Committee 68 Financial Services,9
whose scope is standardization in the field of banking, securities, and other financial
services. Membership consists of 34 participating countries, 50 observing countries,
and 8 liaison relationships to other standards groups. This committee has three standing
subcommittees: SC2 Information Security, SC8 Reference Data, and SC9 Information
Exchange. The committee has several Advisory Groups (AG) and Study Groups (SG)
including SG5 Central Bank Digital Currency (CBDC).
• JTC1 – Another ISO group is Joint Technical Committee One,10 whose scope is stan­
dardization in the field of information technology. Membership consists of 34 partici­
pating countries, 66 observing countries, and 31 liaison relationships to other standards
groups. This committee has 22 subcommittees, including SC27 Information Security,
Cybersecurity, and Privacy Protection, whose focus includes PKI.
• NIST – The National Institute of Standards and Technology11 develops Federal Information
Processing Standards (FIPS) and Special Publications, along with various other technical
specifications.12 All of these are U.S. government documents and are not affiliated with
ANSI or ISO. However, the Information Technology Laboratories (ITL) within NIST is
an ANSI-accredited standards developer. NIST also works with the National Security
Agency13 (NSA) within the Department of Defense14 (DoD) on many standards issues,
including cryptography and key management.
• ITU – The International Telecommunication Union15 (ITU) is the United Nations
specialized agency in the field of telecommunications and Information and
Communications Technologies (ICT) and whose developer group is designed as ITU-T
for Telecommunications Recommendations.16

ITU-T Recommendations include the “X” series for data networks, open system communica­
tions, and security, which includes the recommendation X.509 Information Technology – Open
Systems Interconnection – The Directory: Public Key and Attribute Certificate Frameworks, more
commonly known as X.509 certificates. While most PKI-enabled applications support X.509 cer­
tificates, there are other PKI formatted credentials in use today, such as PGP-type products, EMV
payment smart cards, and numerous others.
Within the realm of less formal standards groups, there are several notable organizations that
have developed numerous cryptography standards that either extend or rely on PKI.

• IEEE – The Institute of Electrical and Electronics Engineers17 (IEEE), pronounced “Eye­
triple-E,” has roots as far back as 1884 when electrical professionalism was new. IEEE
supports a wide variety of standards topics and has liaison status with ISO. Topics include
communications, such as the 802.11 Wireless standards, and cryptography, such as the
1363 Public Key Cryptography standards. Note that the IEEE Standards Association, an
arm of IEEE, is an ANSI-accredited Standards Developing Organization (SDO).
• OASIS – The Organization for the Advancement of Structured Information Standards18
(OASIS), originally founded as “SGML Open” in 1993, is a nonprofit consortium that has
liaison status with ISO. OASIS focuses on Extensible Markup Language (XML) standards,
including the Digital Signature Services (DSS), Key Management Interoperability Protocol
(KMIP) specification, and Security Assertion Markup Language (SAML) specifications.
10 Security Without Obscurity

• W3C – The World Wide Web Consortium19 (W3C) is an international community to

develop web standards including Extensible Markup Language (XML) security such as
the XML Signature, XML Encryption, and XML Key Management standards. W3C also
has liaison status with ISO and collaborates frequently with OASIS and the IETF.
• IETF – The Internet Engineering Task Force20 (IETF) is an international community and
the protocol engineering and development arm for the Internet. The IETF has various
active and concluded security workgroups such as IP Security (IPsec) Protocol, Public Key
Infrastructure X.509 (PKIX), Simple Public Key Infrastructure (SPKI), and Transport
Layer Security (TLS). The IETF is not affiliated with ISO.

The Internet Architecture Board21 (IAB), which formally established the IETF in 1986, is respon­
sible for defining the overall architecture of the Internet, providing guidance and broad direction to
the IETF. The Internet Engineering Steering Group22 (IESG) is responsible for technical manage­
ment of IETF activities and the Internet standards process. In cooperation with the IETF, IAB, and
IESG, the Internet Assigned Numbers Authority23 (IANA) is in charge of all “unique parameters”
on the Internet, including Internet Protocol (IP) addresses.

• PCI SSC – The Payment Card Industry Security Standards Council24 (PCI SSC) is a global
forum established in 2006 by the payment brands: American Express, Discover Financial
Services, JCB International, MasterCard Worldwide, and Visa Incorporated. China Union
Pay (CUP) joined PCI in 2020. PCI develops standards and supports assessment programs
and training, but compliance enforcement of issuers, acquirers, and merchants is solely
the responsibility of the brands. The PCI standards include the Data Security Standard
(DSS), Point-to-Point Encryption (P2PE), and Personal Identification Number (PIN).
The PCI programs include Qualified Security Assessors (QSA), Qualified PIN Assessors
(QPA), Approved Scanning Vendors (ASV), Internal Security Assessors (ISA), and oth­
ers. The PCI SSC is not affiliated with ISO but is an active member of ASC X9.
• RSA Labs – RSA Laboratories is the research center of RSA, the Security Division of
DELL EMC, and the security research group within the EMC Innovation Network. The
group was established in 1991 within RSA Data Security, the company founded by the
inventors (Rivest, Shamir, Adleman) of the RSA public key cryptosystem. RSA Labs
developed one of the earliest suites of specifications for using asymmetric cryptography,
the Public Key Cryptography Standards (PKCS).

While this discussion of standards organizations is not all-encompassing, it does provide an equi­
table overview of groups that have developed or maintain cryptography standards. These groups and
their associated cryptography standards, specifications, and reports are referenced throughout this
book. Technical and security standards are developed at various levels.

• Algorithm standards can define cryptographic processes. An algorithm can be defined

as a process or set of rules to be followed in calculations or other problem-solving oper­
ations, especially by a computer. An algorithm standard defines the inputs, processes,
and outputs, including successful results and error codes. Examples include FIPS 180
Secure Hash Algorithm (SHA), FIPS 186 Digital Signature Algorithm (DSA), FIPS 197
Advanced Encryption Standard (AES), and their successors.
• Protocol standards might incorporate the use of cryptographic algorithms to define cryp­
tographic protocols for establishing cryptographic keying material or exchanging other
information. For example, X9.24 defines three key management methods for establishing
a PIN encryption key used to protect personal identification numbers (PINs) entered at
a point-of-sale (POS) terminal or ATM during transmission from the device to the cor­
responding bank for cardholder authentication. Other key establishment examples include
Introduction 11

X9.42 using discrete logarithm cryptography (e.g., Diffie–Hellman), X9.44 using integer
factorization cryptography (e.g., RSA), and X9.63 using elliptic curve cryptography (ECC).
• Application standards could define how cryptographic algorithms or protocols are used
in a particular technological environment to protect information, authenticate users, or
secure systems and networks. For example, X9.84 defines security requirements for pro­
tecting biometric information (e.g., fingerprints, voiceprints), and X9.95 provides require­
ments and methods for using trusted time stamps. While neither standard deals with
business processes for using such technologies, they do address how to make business
applications more secure.
• Management standards often provide evaluation criteria for performing assessments to
identify security gaps and determine remediation. They may also offer exemplars for
policy or practice statements. In addition to policy or practice examples, management
standards might also provide guidelines for security procedures. Examples include X9.79
and ISO 21188 Public Key Infrastructure (PKI) Practices and Policy Framework.

Ironically, many consider security standards as best practices, such that any subset of a stand­
ard is sufficient; however, most standards represent minimally acceptable requirements. Standards
include mandatory requirements using the reserved word “shall” and recommendations using the
term “should” to provide additional guidance. The “shall” statements represent the minimal controls
and the “should” statements are the best practices.
The standardization process varies slightly between organizations, but many are similar or equiv­
alent. For example, the ASC X9 procedures are modeled after the ISO processes, so we will selec­
tively compare the two. The six stages of an ISO standard are shown in Figure 1.4. The process
begins when a new work item proposal (NWIP) is submitted to one of the ISO technical committees
for consideration as a new standard. The NWIP might be an existing national standard submitted for
internationalization or a proposition of a brand-new standard. The NWIP ballot requires a majority
approval of the technical committee membership, and at least five countries must commit to actively
participate. Once approved, an ISO number is allocated and the work item is assigned to either an
existing workgroup within a subcommittee or possibly a new workgroup is created. Occasionally, a
new subcommittee might be created.
Once the workgroup is established, a working draft (WD) is created. The goal of the WD is to
identify the technical aspects of the draft standard. When the workgroup determines the WD is
ready to be promoted, it can issue a committee draft (CD) ballot. If the CD fails the ballot, then the
workgroup resolves the ballot comments and can attempt another CD ballot. Otherwise, the draft is
considered a CD, and the workgroup continues to develop the remaining technical and supportive
material. When the workgroup determines the CD is ready for promotion, it can issue a draft inter­
national standard (DIS) ballot. If the DIS ballot fails, the workgroup can resolve the comments and
attempt another DIS ballot; otherwise, the DIS is considered stable and is prepared for its Final DIS
(or FDIS) ballot. Upon completion of the FDIS ballot, an ISO audit is performed to ensure the ISO
procedures were followed, and the International Standard (IS) is published. Multiple CD ballots or
DIS ballots are permitted; however, sometimes interest wanes to the point that an insufficient num­
ber of ISO members remain active, and the work item is eventually canceled.

FIGURE 1.4 ISO ballot process.

12 Security Without Obscurity

FIGURE 1.5 X9 ballot process.

The equivalent six stages of an X9 standard are shown in Figure 1.5. Similar to ISO, the X9
process begins when a new work item (NWI) with at least five member sponsors is submitted as
consideration for a new standard. The NWI ballot is at the full X9 committee level, and if approved
an X9 number is allocated and the work item is assigned to either an existing workgroup within a
subcommittee or possibly a new workgroup is created. Again, comparable to the ISO process, a new
subcommittee might be created.
The draft standard is similar to the ISO WD, and once the workgroup decides the standard is
ready, it is issued for a subcommittee (e.g., X9A, X9B, X9C, X9D, or X9F) ballot. If the ballot is
disapproved, then the workgroup resolves the comments and a subcommittee recirculation ballot is
issued, especially when technical changes are made. But even if the ballot is approved, the work-
group still resolves comments. Regardless, once the subcommittee ballot is approved, the draft
standard is then submitted for its full X9 committee ballot, the same ballot process as for the original
NWI ballot. If the X9 ballot is disapproved, the workgroup resolves the comments and a committee
recirculation ballot is issued. And again, even if the ballot is approved the workgroup still resolves
comments. Once the committee ballot is approved, the final draft standard is submitted to ANSI for
a public comment period. All public comments, if any, are resolved by the workgroup, and the final
draft is submitted again to ANSI for an audit to ensure the ANSI procedures were followed, and
finally the American National Standard is published.
The ISO and ANSI consensus process helps ensure industry representation by interested partici­
pants. The standards process is often referred to as the “alphabet soup,” which is understandable due
to the many organizations and numbers. However, the standards process is important for industry
consistency, continuity, and interoperability. This is especially important for cryptography and PKI
Cryptonomics as parties need to establish trusted relationships. If one party cannot trust the cryp­
tographic keys and particularly the public key certificates of the other, then the data and interactions
cannot likewise be trusted.

NOTES
1. Cryptonomics originated in the first edition Security Without Obscurity: A Guide to PKI Operations in 2016
but since then has been adopted by others.
2. Payment Card Industry (PCI) Security Standards Council (SSC). Data Security Standard (PCI DSS v3.1):
Requirements and security assessment procedures, www.pcisecuritystandards
3. https://en.wikipedia.org/wiki/Caesar_cipher
4. www.monticello.org/site/research-and-collections/wheel-cipher
5. www.bbc.co.uk/history/worldwars/wwtwo/enigma_01.shtml
6. International Organization for Standardization, www.iso.org.
7. International Committee for Information Technology Standards, www.incits.org.
8. Accredited Standards Committee X9, www.x9.org.
9. ISO TC69, www.iso.org/committee/49650.html
10. www.iso.org/committee/45020.html
11. National Institute for Standards and Technology, www.nist.gov
12. Computer Security Resource Center of NIST, csrc.nist.gov/publications
13. National Security Agency, www.nsa.gov
Introduction 13

14. Department of Defense, www.dod.gov.

15. International Telecommunications Union, www.itu.itl
16. ITU Telecommunications Recommendations, www.itu.int/en/ITU-T/Pages/default.aspx
17. Institute of Electrical and Electronics Engineers, www.ieee.org
18. Organization for the Advancement of Structured Information Standards, www.oasis-open.org
19. World Wide Web Consortium, www.w3c.org
20. Internet Engineering Task Force, www.ietf.org
21. Internet Architecture Board, www.iab.org
22. Internet Engineering Steering Group, www.ietf.org/iesg/index.html
23. Internet Assigned Numbers Authority, www.iana.org
24. Payment Card Industry Security Standards Council, www.pcisecuritystandards.org
 2 Cryptography Basics

The security basics, confidentiality, integrity, authentication, authorization, accountability, and

nonrepudiation were discussed in Chapter 1, “Introduction.” In this chapter, we discuss how cryp­
tography can help achieve many of these controls. We will apply these concepts to the operations
of PKI and how PKI can deliver on the promise of these controls. From a cryptographic point
of view, as shown in Table 2.1, some security basics have equivalent cryptography basics, while
some of the security basics merge into a single cryptography basic, and we need to add some new
cryptography basics.
Cryptography is literally defined as the process of writing or reading secret messages,1 whereas
cryptanalysis is the breaking of those secret messages. However, the term “cryptography” has
evolved from its origins of just data confidentiality (secret messages) to include methods for integ­
rity, authenticity, and nonrepudiation. A common misnomer is interchanging the terms “encryption”
and “cryptography” – they are not equivalent, as encryption is one of many cryptographic mecha­
nisms. As was provided in Chapter 1, “Introduction,” for security basics and for the purposes of this
book, we provide the following basic definitions of cryptography:

• Algorithms are a set of rules for mathematical calculations or other problem-solving oper­
ations including cryptographic processes. Ciphers are a method for making information
secret, which includes encryption algorithms, but not all cryptographic algorithms are
necessarily ciphers, and some provide authentication, nonrepudiation, or key management
services.
• Encryption is the process of transforming original information called “cleartext” to an
undecipherable format called “ciphertext,” which provides data confidentiality. The reverse
process is called “decryption,” which changes ciphertext back to cleartext for recover­
ing the original information. The cryptographic key is commonly called the encryption
key regardless of if the cleartext is being encrypted or the ciphertext is being decrypted.
Without access to the encryption key, cleartext cannot be encrypted and ciphertext cannot
be decrypted by any other party.

TABLE 2.1
Security and Cryptography Basics
Security Basics Cryptography Basics Rationale
Confidentiality Encryption Confidentiality and encryption controls are essentially equivalent
methods.
Integrity Cryptographic Signature Cryptographic signatures include symmetric and asymmetric signatures.
Authentication Cryptographic Authentication Cryptographic authentication is based on security protocols using
cryptographic methods.
Authorization Cryptographic Credential Cryptographic credentials include X.509 public key and attribute
credentials.
Accountability Log Management Log management is an information technology control applied to
cryptographic methods.
Key Management Key management is specific to cryptography.
Cryptographic Module Cryptographic hardware and software modules are specific to
cryptography.
Nonrepudiation Nonrepudiation Nonrepudiation is based on digital signatures.

14 DOI: 10.1201/9781003425298-2
Cryptography Basics 15

• Cryptographic authentication is the process of deriving an authentication token from

original information, sometimes just called a “token” or “authenticator.” The token is a
cryptographic pseudonym of the original data. The corresponding process verifies the
token that provides both authentication and data integrity to a “relying” party. In this use
case, the cryptographic key is commonly called an authentication key. Without access to
the authentication key, the token cannot be generated or verified by any other party.
This type of cryptographic authentication should not be confused with the three basic
authentication methods: something you know (knowledge factor), something you have
(possession factor), and something you are (biometrics). While some methodologies
include cryptographic keys as possession factors, this book considers cryptography as a
fourth “something you control” factor. However, symmetric keys and asymmetric private
keys should never be known – see Section 2.4, “Key Management,” for a discussion on the
key management lifecycle.
• Nonrepudiation is the process of deriving a nonrepudiation token from original infor­
mation, usually called a “signature.” Similar to an authentication token, the signature is
a cryptographic pseudonym of the original data, and the corresponding process is also
verification to a relying party.
The additional attribute for nonrepudiation is that the authentication and integrity are
provable to an independent third party, such that the signer cannot refute a legitimate sig­
nature. It is important to understand this is a technical definition of nonrepudiation, and
many lawyers will argue the legal definition of the term; for the purposes of this book, we
will be using the technical definition and not the legal one. Nonrepudiation and legal con­
siderations are discussed further in Chapter 9, “PKI Governance, Risk, and Compliance.”
This type of signature should not be confused with an “electronic signature” that is
defined in the Electronic Signatures in Global and National Commerce Act (the ESign
Act) of 2000 as an electronic sound, symbol, or process attached to or logically associ­
ated with a contract or other record and executed or adopted by a person with the intent to
sign the record. However, the ESign “process” definition allows for cryptographic signa­
tures, commonly called digital signatures, which can be used for nonrepudiation services.
Electronic signatures and nonrepudiation services are discussed further in Chapter 9.
• Key management is the process of securely managing cryptographic keys over their lifecy­
cle, including key generation, distribution, usage, backup, revocation, termination (which
includes key destruction), and archive phases. Generation is when keys are created for a
specific algorithm, purpose, strength, and lifetime. Distribution occurs when keys need to
be established at more than one location beyond their generation site. Usage is when and
where keys are employed per their intended purpose. Backup is done for business conti­
nuity or disaster recovery to reestablish keys due to various failures. Revocation is done
only when keys are no longer viable prior to their original expiration date. Termination is
the removal of previously established keys upon their end of life or revocation. Archival is
for retaining certain keys past their usage period for various legal or contractual reasons.
• Cryptographic modules include both hardware and software implementations. The
National Institute of Standards and Technology (NIST) describes a cryptographic module
as including, but not limited to, hardware components, software or firmware programs,
or any combination thereof [B.5.3]. Cryptographic keys are used with cryptographic algo­
rithms and functions embodied in software, firmware, or hardware components.

In general, cryptographic algorithms are divided into symmetric and asymmetric algorithms. Sym­
metric ciphers use the same key to encrypt and decrypt data, whereas asymmetric ciphers use two
different keys. Figure 2.1 shows a functional diagram with two inputs (parameters and key) and
one output (results). The nomenclature and graphics used in Figure 2.1 are used for all diagrams
used in this book. The function is a cryptographic operation based on a cryptographic algorithm, for
16 Security Without Obscurity

FIGURE 2.1 Cryptographic functions.

example, a cryptographic algorithm might include encryption and decryption functions. The request
parameters typically include a command, the data, and associated options. The cryptographic key
instructs the algorithm as to how it manipulates the input data. The results provide the output data
and usually include a return code indicating success or an error.
Symmetric and asymmetric algorithms and functions are discussed in Section 2.1, “Encryp­
tion,” Section 2.2, “Authentication,” and Section 2.3, “Nonrepudiation.” Where, when, and how
cryptographic keys are stored are in Section 2.4, “Key Management.” Where and how functions
are accessed by applications when using cryptographic algorithms are discussed in Section 2.5,
“Cryptographic Modules.” This book refers to various standards and specifications that define cryp­
tographic algorithms, modes of operations, and associated options, but it does not provide process
details or descriptions of the underlying mathematics [B.7.4].

2.1 ENCRYPTION
When describing a symmetric algorithm, sometimes called a symmetric cipher, it is easiest to con­
sider the overall process between a sender and a receiver. Figure 2.2 shows a sender encrypting the
cleartext and sending the ciphertext to the receiver and then a receiver decrypting the ciphertext to
recover the original cleartext. Both parties use the same cryptographic algorithm and key, but the
sender uses the encrypt function, while the receiver uses the decrypt function. Since the same key is
used for both encryption and decryption, this is called a symmetric algorithm with a symmetric key.
Furthermore, any interloper without access to the same symmetric key cannot decrypt the
ciphertext, and therefore the encryption provides data confidentiality. An outsider might attempt an
exhaustive key attack, that is, try every possible key until the right one is determined. There are no
protections against an exhaustive attack except for the huge number of possible keys provided by
the size of the symmetric key used to encrypt the cleartext; given enough time and resources, the
symmetric key can theoretically be found.
In fact, there is always a nonzero probability that a key can be found, and it is actually possible
but highly unlikely that the first guess happens to be the correct key. In comparison, a winning lot­
tery ticket with 6 out of a possible 100 numbers is 100 × 99 × 98 × 97 × 96 × 95 = 858,277,728,000

FIGURE 2.2 Symmetric encryption.

Cryptography Basics 17

or one chance in about 858 billion (a billion is 109 or 9 zeroes), which is better than one chance in
a trillion (or 1012 or 1 with 12 zeroes after it). A modern symmetric algorithm using a 128-bit key
has more than 340 × 1036 possible keys, which is a number that has 27 more zeroes than the lowly
lottery ticket’s chance of winning.
Thus, the huge number of possible symmetric keys typically makes an exhaustive attack imprac­
tical. In addition, if the key can be found within someone’s lifetime, the value of the recovered
cleartext is likely expired or useless. For example, if it takes 30 years to determine a key used to
encrypt a password that was only valid for 30 days, the attack is essentially a waste of time. Fur­
thermore, changing the key periodically is a common countermeasure, such that the time needed to
exhaustively determine a symmetric key often far exceeds its actual lifetime.
However, there are far easier attacks to get the symmetric key. For example, in order for the
sender and receiver to exchange the encrypted information (ciphertext) and decrypt it, they must
first exchange the symmetric key, which, if not done in a secure manner, might allow an outsider to
get the key. Furthermore, in order for the sender to encrypt and the receiver to decrypt, they must
have access to the same key. Inadequate key storage protection might allow an outsider to hack into
the systems and get the key or an unauthorized insider to access the systems and provide the key to
the outsider. Related vulnerabilities, threats, and risks are discussed in more detail in Section 2.4.
However, insider threats are more likely to occur than outsider threats. The Ponemon Institute2 and
Raytheon released a 2014 study on insider threats including both adversarial and inadvertent secu­
rity breaches:

• Eighty-eight percent of respondents recognize insider threats as a cause for alarm but have
difficulty identifying specific threatening actions by insiders.
• Sixty-five percent of respondents say privileged users look at information because they
are curious.
• Forty-two percent of the respondents are not confident that they have enterprise-wide vis­
ibility for privileged user access.

The 88% of respondents who recognize a cause of alarm toward insider threats seem justified by
other studies such as the Carnegie Mellon University and Software Engineering Institute study
on insider threats in the U.S. Financial Services Sector,3 which provides a damage comparison
between internal and external attacks. The study was based on 80 fraud cases between 2005 and
2012. On average, the actual internal damage exceeded $800,000, while the average internal
potential was closer to $900,000. In comparison, the actual average external damage was over
$400,000, and the potential average external damage was closer to $600,000. The study indicates
that insider damage is doubled (or 100% greater), while its potential is a third higher (or about
33% greater).
When describing an asymmetric algorithm, also called an “asymmetric cipher,” it is easier to
consider the overall process between a sender and a receiver, as we did for symmetric algorithms.
Figure 2.3 shows a sender encrypting cleartext using the receiver’s public key, sending the ciphertext

FIGURE 2.3 Asymmetric encryption.

18 Security Without Obscurity

to the receiver, and then the receiver decrypting the ciphertext using its private key to recover the
cleartext. The receiver generates an asymmetric key pair consisting of the private key and the public
key and sends its public key to the sender. Similar to symmetric ciphers, both parties used the same
cryptographic algorithm but with this example, each used a different key. Since different keys are
used, the public key for encryption and the private key for decryption, this is called an asymmetric
algorithm with an asymmetric key pair.
The cleartext encrypted using the public key can only be decrypted using the corresponding
private key. Thus, any sender with a copy of the public key can encrypt cleartext but only the
receiver can decrypt the ciphertext. Thus, any interloper with a copy of the receiver’s public key
cannot decrypt the ciphertext so the data confidentiality is maintained. Furthermore, the distribu­
tion of the asymmetric public key does not require secrecy as does a symmetric key. On the other
hand, the asymmetric private key is as vulnerable to outside hackers or insider threats as any sym­
metric key. In general, the same key management controls used for symmetric keys are equally
needed for asymmetric private keys. However, as we dig deeper into PKI operations further in
the book, it will become readily apparent that the strongest controls are needed for asymmetric
private keys.
With respect to asymmetric public keys, we mentioned earlier that they do not need to be kept
secret; however, they do require authenticity. Otherwise, without the sender being able to authen­
ticate the receiver’s public key, asymmetric cryptography is susceptible to a “man-in-the-middle”
(MITM) attack as shown in Figure 2.4. Consider the same scenario of a sender sending ciphertext
to the receiver by encrypting the cleartext with a public key. The MITM attack occurs when an
interloper convinces the sender that its public key belongs to the receiver. The sender encrypts the
cleartext with the interloper’s public key, thinking it is using the receiver’s public key, and sends
the ciphertext to the receiver, which the interloper intercepts. The interloper decrypts the cipher-
text using its private key to recover the original cleartext, then re-encrypts the cleartext using the
actual receiver’s public key and sends the ciphertext onto the receiver. The receiver decrypts the
ciphertext using its private key to recover the original cleartext, unaware that the interloper has
accessed the message.
The sender falsely believes it is securely exchanging information with the receiver as shown
by the dotted line, but the interloper is the man in the middle. Furthermore, the interloper not only
sees the original cleartext from the sender but also changes the cleartext such that the sender sends
one message but the receiver gets a completely different message, and neither of them is aware of
the switch. Often, asymmetric encryption is not used for exchanging data but rather for exchanging
symmetric keys, which are subsequently used to encrypt and decrypt data. So, a MITM attack would
capture the symmetric key again allowing the interloper to encrypt and decrypt information. To
avoid a MITM attack, the sender must be able to validate the public key owner, namely, the receiver,
which is discussed in Section 2.2.

FIGURE 2.4 Asymmetric man-in-the-middle (MITM) encryption.

Cryptography Basics 19

2.2 AUTHENTICATION
We now continue the sender and receiver discussion from Section 2.1, “Encryption,” when using
symmetric and asymmetric ciphers for authentication and integrity.
Figure 2.5 shows a sender generating a Message Authentication Code (MAC) using a symmetric
encryption function. The MAC is generated using a specific cipher mode of operation called cipher
block chaining (CBC). Basically, the cleartext message is divided into chunks of data, each chunk is
encrypted such that the ciphertext from the previous encryption is used with the next encryption, and
the MAC is the first half of the last ciphertext block [B.4.9] and [B.4.3]. Both parties use the same
cryptographic algorithm, the same symmetric key, and the same encrypt function.
The sender generates the MAC from the cleartext and sends both the cleartext message and the
MAC to the receiver. The receiver generates its own MAC from the cleartext message and compares
the received MAC to the newly generated MAC. If the two match, then the receiver has validated
that the cleartext message (and the MAC) has not been altered, and therefore the message integrity
has been verified. Furthermore, since only the sender and the receiver have access to the MAC key
and the receiver did not send the cleartext message, the MAC also provides message authentication.
Additional services are discussed in Section 2.3, “Nonrepudiation.”
Figure 2.6 shows a sender generating a keyed Hash Message Authentication Code (HMAC)
using a hash algorithm instead of a symmetric cipher. In general, a hash function maps data of an
arbitrary large size to data of a smaller fixed size, where slight input differences yield large output
differences. A cryptographic hash function must be able to withstand certain types of cryptanalytic
attacks. At a minimum, cryptographic hash functions must have the following properties:

• Preimage resistance is with regard to a known message: it must be infeasible to determine

the original message m from just the hash result h, where h = hash (m).
• Second preimage resistance is with regard to a known message and an unknown message:
it must be infeasible to find a second message g that yields the same hash result as message

FIGURE 2.5 Symmetric Message Authentication Code (MAC).

FIGURE 2.6 Symmetric Hash Message Authentication Code (HMAC).

20 Security Without Obscurity

m, where h = hash (m) = hash (g). This resistance deters an attacker from finding a second
message that might be used to counterfeit the first message.
• Collision resistance is with regard to two unknown messages: it must be infeasible to find
any two messages m and g that yield the same hash results h, where h = hash (m) = hash
(g). This resistance is analogous to the birthday paradox, finding two individuals with the
same birthday within a room of people.

If any of these conditions are not met, then an interloper might be able to determine another
cleartext message and substitute it for the original message. A sender or a receiver might also be able
to determine another message claiming it was the original message and so repudiate the message.
Otherwise, similar to the MAC, the HMAC algorithm [B.5.7] incorporates a symmetric key with the
cryptographic hash function used by the sender and the receiver.
The sender generates the HMAC from the cleartext and sends both the cleartext message and the
HMAC to the receiver. The receiver generates its own HMAC from the cleartext message and com­
pares the received HMAC to the newly generated HMAC. If the two match, then the receiver has
validated that the cleartext message (and the HMAC) has not been altered, and therefore the mes­
sage integrity has been verified. Since only the sender and the receiver have access to the HMAC
key, and the receiver did not send the cleartext message, the HMAC also provides message authen­
tication. Additional services are discussed in Section 2.3, “Nonrepudiation.”
Figure 2.7 shows a sender generating a digital signature, sometimes just called a signature, using
a combination of a hash function and a digital signature algorithm.
The differences between asymmetric encryption (see Section 2.1) and digital signatures include
the following:

• The sender uses its own private key to generate the signature versus the receiver’s public
key to encrypt data.
• The receiver uses the sender’s public key to verify the signature versus its own public key
to encrypt the data.

Similar to HMAC, the sender generates a hash of the cleartext, but then uses its private key to gener­
ate the signature, so the sender is often called the signer. The cleartext and signature are sent to the
receiver, who then generates its own hash of the cleartext, and then uses the sender’s public key to
verify the signature. In fact, any receiver who has a copy of the sender’s public key can verify the
sender’s signature. Furthermore, only the sender can generate the signature as only it has access to
its private key.

FIGURE 2.7 Asymmetric digital signature.

Cryptography Basics 21

The sender (or signer) generates a hash from the cleartext and uses its asymmetric private key to
generate the digital signature. The cleartext message and the digital signature are sent to the receiver.
The receiver generates its own hash from the cleartext message and verifies the signature using
the sender’s public key. If the signature verifies, then the receiver has validated that the cleartext
message has not been altered, and therefore the message integrity has been verified. Since only the
sender has access to the private key, the signature also provides message authentication. Additional
services are discussed in Section 2.3.
As mentioned in Section 2.1, “Encryption,” asymmetric public keys do not need to be kept
secret; however, they do require authenticity. Otherwise, without the receiver being able to authen­
ticate the sender’s public key, asymmetric cryptography is susceptible to a MITM attack as shown
in Figure 2.8. Consider the same scenario of a sender sending a signed message to the receiver by
hashing the cleartext and generating the signature using its private key. A MITM attack occurs when
an interloper convinces the receiver that its public key belongs to the sender. The sender generates
the digital signature using its private key, which the interloper cannot counterfeit. However, the
interloper intercepts the cleartext message and generates a new digital signature using its private
key. The interloper sends the re-signed message to the receiver. The receiver uses the interloper’s
public key, believing it is the sender’s public key, and successfully verifies the digital signature.
The receiver thinks it has verified a signed message from the sender, unaware that the interloper
is the man in the middle. The interloper can modify or substitute the cleartext message such that the
sender signs one message but the receiver verifies another, and neither of them is aware of the switch.
To avoid a MITM attack, the receiver must be able to validate the public key owner, namely, the
sender. This is accomplished by encapsulating the sender’s public key in a PKI credential, commonly
called public key certificate, sometimes called a digital certificate or just certificate, signed and issued
by a trusted third party (TTP) called a certificate authority (CA). The standards that define the cer­
tificate contents and the CA operations are discussed in Section 3.1, “PKI Standards Organizations,”
but here, we introduce the basic concepts regarding the authenticity and integrity of the public key.
Let’s review Figure 2.7, where the sender signs a cleartext message using its asymmetric private
key and sends the original cleartext and signature to the receiver for verification using the sender’s
asymmetric public key. Let’s also reconsider Table 2.2 using the same scenario. It is important to rec­
ognize that there are two very different signatures – the signature for the cleartext message generated
by the sender and the signature for the certificate generated by the issuer. And as we will explain,
the receiver will need to verify both signatures in the overall authentication and integrity validation.

• Subject name is the public key owner’s name, in this case the sender.
• Subject public key is the subject’s public key, in this case the sender’s public key.

FIGURE 2.8 Asymmetric man-in-the-middle (MITM) signature attack.

22 Security Without Obscurity

• Issuer name is the certificate signature signer’s name; in this case, we introduce another
entity, the CA.
• Issuer signature is the issuer’s digital signature, in this case the CA’s signature generated
by the CA’s asymmetric private key. This signature encapsulates the certificate informa­
tion like an envelope; that is, the subject, the public key, and the issuer fields are hashed,
and the issuer’s asymmetric private key is used to generate the certificate signature.

Furthermore, the receiver is the relying party using the sender’s public key to verify the sender’s
signature on the cleartext message, but not until after the receiver uses the CA’s public key to verify
the signature on the certificate. As shown in Table 2.2, the certificate signature is over the certifi­
cate fields, which provides cryptographic bindings between the sender’s name and public key and
between the sender’s name and the CA’s name. Thus, the receiver can rely on the sender’s public key
to verify the cleartext message because the sender’s certificate has been validated using the CA’s pub­
lic key (Figure 2.9). However, the validation process for verifying the sender’s certificate and related
CA certificates, called the certificate chain, shown in Figure 2.10 is discussed in the succeeding text.
Since hashing the cleartext is always part of generating the digital signature, for the remainder of
this chapter, the hash step will not be shown. We also introduce two important concepts for confirm­
ing a digital signature – verification versus validation:

• Verification is the partial confirmation consisting of a single cryptographic object, such

as a digital signature or a digital certificate. For example, an individual signature can be
verified using a public key; however, without proper validation, the public key cannot be
trusted as it requires authentication.
• Validation is the complete end-to-end confirmation of the certificate chain, including the
end-user certificate, the intermediate CA certificates, and the root CA certificates, as well
as the checking of the validity dates and status of each certificate.

TABLE 2.2
Selected Certificate Fields
Certificate Fields Certificate Fields Description
Subject name Subject is the public key owner’s name.
Subject public key Public key is the subject’s public key.
Issuer name Issuer is the TTP signer’s name.
Issuer signature Signature is the TTP digital signature of the certificate.

FIGURE 2.9 Certificate basics.

Cryptography Basics 23

FIGURE 2.10 Basic certificate signature verification.

Figure 2.10 demonstrates a signed cleartext message, the signer’s certificate, an issuer CA cer­
tificate, and a root CA certificate. In order for the relying party to verify the signed message, it
must validate the certificate chain, consisting of the subject (signer), issuer CA, and root CA
certificates.
However, in order to validate the certificate chain, the relying party must first determine the cer­
tificate chain. This is accomplished by walking the certificate chain in the following manner – refer
to the dotted line from left to right:

(1) The relying party matches the signer’s name with the subject name in the signer’s certifi­
cate to find the signer’s public key. This presumes the relying party has a means by which
to identify the signer’s name, also called an identity.
(2) The issuer CA name in the signer’s certificate is then matched with the issuer CA name
in the issuer CA certificate to find the issuer CA’s public key.
(3) The root CA name in the issuer CA certificate is then matched with the root CA name in
the root CA certificate to find the root CA’s public key.

Once the certificate chain is determined and each participant’s public key has likewise been estab­
lished, the relying party can then walk the chain in reverse and verify the signature on each certifi­
cate in the following manner – refer to the solid line from right to left:

1. The root CA public key is used to verify the signature on the root CA certificate. It is
important to note that since the root CA is the apex of the hierarchy, there is no other
entity to sign the root CA certificate, and therefore it is a self-signed certificate. Root
CA certificates are installed in a reliable and secure storage, often called a trust store, to
ensure and maintain its authenticity and integrity. Once the certificate signature has been
verified, its public key can be used to verify the next certificate in the chain.
2. The root CA public key is then used to verify the signature on the issuer CA certificate,
such that once the certificate signature has been verified, its public key can be used to
verify the next certificate in the chain.
3. The issuer CA public key is then used to verify the signature on the subject certificate,
such that once the certificate signature has been verified, its public key can be used to
verify the next certificate in the chain.

The subject public key can then be used to verify the signature on the cleartext message, which
authenticates the signer and provides message integrity. It is important to note that Table 2.2
and Figure 2.10 do not list all of the fields in a standard certificate. Individual certificate veri­
fication and certificate chain validation are more complex than discussed so far. In addition to
signatures, validity dates and certificate status must also be checked. Refer to Chapter 3, “PKI
Building Blocks,” for certificate formats and Chapter 5, “PKI Roles and Responsibilities,” for
more details.
24 Security Without Obscurity

FIGURE 2.11 Subject self-signed certificates.

SPECIAL NOTE 2‑1 SELF‑SIGNED CERTIFICATES

Relying on self-signed certificates is a bad practice since they do not authenticate the subject
of the certificate and because the contents are unreliable.

Except for root CA certificates that are installed and protected in trust stores to ensure and main­
tain their authenticity and integrity, subject self-signed certificates are unreliable. An example is
shown in Figure 2.11 with the signer sending a signed cleartext message. The left side shows the
legitimate sender signing the cleartext that can be verified using the sender’s self-signed certificate.
However, on the right side, an interloper has resigned modified cleartext but substituted a counterfeit
self-signed certificate that contains the sender’s name but the interloper’s public key. The relying
party verifies the signature on the substituted cleartext unknowingly using the interloper’s certif­
icate. Both the interloper’s certificate and signed message verify because they were signed by the
interloper’s private key, but the relying party cannot distinguish between the sender’s real certificate
and the interloper’s certificate. Thus, the content of a subject self-signed certificate is unreliable.
The discussions on certificate verification and certificate chain validation employed examples
where the subject’s public key was used to verify signed cleartext messages. It is important to rec­
ognize that a subject’s asymmetric private key and certificate can be used for many other purposes
including data encryption discussed in Section 2.1, “Encryption,” key encryption discussed in Sec­
tion 2.4, “Key Management,” code signing, e-mails, and time stamps. Digital signatures for achiev­
ing nonrepudiation are discussed in Section 2.3, “Nonrepudiation,” and cryptographic modules to
protect asymmetric keys are discussed in Section 2.5, “Cryptographic Modules.”

2.3 NONREPUDIATION
As described earlier, nonrepudiation is the process of deriving a nonrepudiation token from origi­
nal information, usually called a signature. First, let’s discuss why some of the other integrity and
authentication mechanisms cannot provide nonrepudiation services.
Let’s reconsider Figure 2.5, where the sender sends both the cleartext message and the MAC to
the receiver for message integrity. Since only the sender and the receiver have access to the MAC
key and the receiver did not send the cleartext message, the MAC also provides message authentica­
tion. However, since both the sender and the receiver have access to the MAC key and can generate
the MAC, either might have also created the message, so the authentication and integrity are not
provable to an independent third party, and therefore the MAC cannot provide nonrepudiation.
Arguably, a symmetric cipher scheme might be used for nonrepudiation. For example, as shown in
Figure 2.12, if an authentication system enforced the use of two separate MAC keys, one for sending
and the other for receiving, then this might meet third-party provability. But, unlike asymmetric ciphers,
the key separation controls are not inherent within the cryptography but rather part of the application.
Thus, the MAC keys are generated and exchanged with send-only and receive-only controls strictly
enforced. For example, Party A might generate its send-only key, and when exchanged with Party B,
Cryptography Basics 25

the key is installed as a receive-only key. Likewise, Party B would generate a different send-only key,
and when exchanged with Party A, the key is installed as a receive-only key. Clearly, additional access
and execution controls are needed for this scenario. Regardless, while the cryptography scheme is an
important aspect of the overall nonrepudiation services, it is not the only consideration.
Likewise, let’s reconsider Figure 2.6, where the sender sends both the cleartext and HMAC to the
receiver for message integrity. Since only the sender and the receiver have access to the HMAC key and
the receiver did not send the cleartext message, the HMAC also provides message authentication. How­
ever, since both the sender and the receiver have access to the HMAC key and can generate the HMAC,
either might have also created the message, so the authentication and integrity are not provable to an
independent third party, and therefore the HMAC cannot provide nonrepudiation. Arguably, using two
separate HMAC keys, one for sending and the other for receiving, might meet third-party provability,
but again the cryptographic scheme is not the only consideration for nonrepudiation services.
Now let’s reconsider Figure 2.7, where the sender sends both the cleartext and signature to the
receiver for message integrity. Since only the sender has access to the private key, the signature also
provides message authentication. Because the signature can only be generated using the private
key, the authentication and integrity are provable to an independent third party, and therefore the
signature can provide nonrepudiation. But once again, the cryptographic scheme is not the only
consideration for nonrepudiation services.
Another method involves a combination of cryptographic hashes and digital signatures shown in Fig­
ure 2.13. Here, we provide an overview of trusted time stamp technology and the use of a Time Stamp

FIGURE 2.12 Message Authentication Code (MAC) nonrepudiation.

FIGURE 2.13 Time Stamp Token (TST).

26 Security Without Obscurity

Authority (TSA). The first step occurs when Party A generates a hash of its cleartext denoted hash(C)
and provides it to the TSA, requesting a Time Stamp Token (TST). The TSA operates independently of
Party A as either an external organization or a service encapsulated within a cryptographic module. Fur­
thermore, the TSA never has access to the original cleartext, only the hash(C) of the cleartext [B.1.15].
The second step takes place when the TSA generates a Time Stamp Token (TST) by adding a time
stamp to the submitted hash(C) and generating a signature over both elements. The TSA generates
its own hash of the hash(C) and the time stamp and applies its private key to generate the signature.
The time stamp is from a clock source that is calibrated to the International Timing Authority (ITA).
Calibration means the time difference between the TSA clock and the ITA clock is registered; the
clocks are not synchronized, as that would change the TSA clock. Other cryptographic mechanisms
such as hash chains, MAC, or HMAC might be used; however, for the purposes of this book, we
only refer to digital signatures. The TSA returns the TST to Party A.
The third step happens when Party A provides its cleartext message and the corresponding TST
to Party B. Party B regenerates hash(C) from the cleartext and matches it to the hash(C) in the TST.
Party B then verifies the TST signature using the TSA’s public key. The TSA signature cryptograph­
ically binds the original hash(C) to the time stamp such that when Party B validates the TST, the
following has been proved:

• The TST signature authenticates that the TST was generated by the TSA.
• The TST hash(C) confirms the integrity of the cleartext provided by Party A.
• The TST time stamp confirms the reliability of the cleartext to a verifiable time source.

The cleartext created by Party A might be content for a website, a legal document, a financial state­
ment, or even an executable code. Party B can then be assured that whatever the nature of the cleart­
ext, its integrity is provable to a verifiable point in time. Furthermore, if Party A signed the cleartext
such that the hash(C) includes the cleartext and the digital signature, then Party B not only has assur­
ance of the cleartext but can also prove that Party A signed the cleartext no later than the time stamp.
However, all of these methods are from a cryptographic viewpoint of nonrepudiation, and there
are additional operational and legal considerations. From an operation perspective, controls over the
symmetric or asymmetric private keys are paramount. Controls over the application using the keys are
likewise as important. Finally, the reliability and robustness of the protocol are also essential. There are
many operational considerations that might undermine the effectiveness of a nonrepudiation service:

• Key compromise allowing misuse by another system or application

• Unauthorized access to the key allowing system misuse
• Unauthorized access to the application allowing operational misuse
• Vulnerability in the protocol enabling spoofing or key compromise

From a legal perspective, the nonrepudiation service needs to provide a dispute resolution process
and, if not settled, needs to be resolved in litigation or arbitration. For the latter case, the presence
of the nonrepudiation token (e.g., digital signature) needs to be admissible per the established rules
of evidence. The operational controls discussed earlier need to be discoverable and confirmed. This
might include interviewing witnesses involved in the dispute or expert testimony with regard to the
nonrepudiation services or general cryptography. Legal issues regarding nonrepudiation are dis­
cussed further in Chapter 9, “PKI Governance, Risk, and Compliance.”

2.4 KEY MANAGEMENT

As described earlier, key management is the process for managing keys across their lifecycle, and as
discussed in Section 2.1, “Encryption,” and Section 2.2, “Authentication,” cryptography is organ­
ized into two areas of study: symmetric and asymmetric algorithms. Symmetric ciphers use the same
Cryptography Basics 27

key for related functions, and asymmetric ciphers use different keys (public and private) for related
functions. For symmetric ciphers, we discussed the following cryptographic operations:

• Encryption and decryption of data using a symmetric data encryption key (DEK).
• Generation and verification of a Message Authentication Code (MAC) using a symmetric
MAC key.
• Generation and verification of a keyed Hash Message Authentication Code (HMAC)
using a symmetric HMAC key.

For asymmetric ciphers, we discussed the following cryptographic operations:

• Encryption and decryption of data using an asymmetric key pair, where the data are
encrypted using the public key and decrypted using the associated private key.
• Signature generation and verification using an asymmetric key pair, where the signature
is generated using the private key and verified using the corresponding public key.

In addition to the aforementioned operations, we now discuss additional key management functions
for both symmetric and asymmetric algorithms:

• Encryption and decryption of other keys using a symmetric key encryption key (KEK).
• Encryption and decryption of symmetric keys using an asymmetric key pair, where the
key is encrypted using the public key and decrypted using the associated private key.
• Negotiation of symmetric keys using asymmetric key pairs; both parties use their private
key, their public key, and the public key of the other party to derive a shared value.

In general, when a symmetric key is generated by one party and transmitted as ciphertext to the other
party, this is called key transport. Conversely, when both sides negotiate the symmetric key without
having to transmit it as ciphertext, this is called key agreement. Key transport and key agreement are
collectively called key establishment. Figure 2.14 shows the encryption, transmission, and decryp­
tion of a symmetric key.
The sender generates a random symmetric key, encrypts it using a symmetric KEK, and trans­
mits the ciphertext to the receiver. The receiver decrypts the ciphertext using the same KEK to
recover the newly generated symmetric key. The KEK would have been previously established
between the sender and the receiver and used exclusively for key encryption. There are several
methods to establish a KEK including asymmetric key transport or key agreement protocol, or
manual methods including key components or key shares, commonly called key splits in this book.
Each of these methods has strengths and weaknesses, which are discussed further in more detail.
The most important aspect of establishing a KEK, especially when using manual methods, is having
documented procedures with good practices that are followed and kept as an audit log for subse­
quent review and confirmation.

FIGURE 2.14 Symmetric key transport.

28 Security Without Obscurity

The purpose of the exchanged symmetric key is indeterminate without a bilateral agreement
between the sender and the receiver or additional information transmitted along with the cipher-
text. Such information about the exchanged symmetric key might be included as part of a key
exchange protocol. For example, in Figure 2.12, we identified the scenario of exchanging not
only a MAC key but also the key’s directional usage (send vs. receive) as part of its control
mechanisms. Some key establishment protocols provide explicit key exchange parameters, while
others are implicit. Some data objects such as digital certificates or encrypted key blocks include
explicit key usage information that applications are expected to obey. Some cryptographic prod­
ucts enforce key usage controls, while others do not. And sometimes the key exchange purpose
is merely a contractual agreement between the participating parties with manual procedures that
might require dual controls.
Figure 2.15 also depicts the encryption, transmission, and decryption of a symmetric key. Exam­
ples of key transport schemes include RSA Optimal Asymmetric Encryption Padding (OAEP) and
the RSA Key Encapsulation Mechanism and Key Wrapping Scheme (KEM-KWS) methods [B.1.6]
based on the paper “Method for Obtaining Digital Signatures and Public Key Cryptosystems”
[B.7.5], published in 1976.
The sender generates a random symmetric key, encrypts it using the asymmetric public key of
the receiver, and transmits the ciphertext to the receiver. The receiver decrypts the ciphertext using
its asymmetric private key to recover the newly generated symmetric key. The receiver’s public
key would have been previously provided to the sender and used exclusively for key transport. Not
shown is the encapsulation of the receiver’s public key in a certificate. As discussed in Section 2.2,
“Authentication,” without the use of a digital certificate, the key transport is also vulnerable to a
MITM attack, as shown in Figure 2.16. The presumption is the sender erroneously uses the interlop­
er’s public key instead of the receiver’s public key.

FIGURE 2.15 Asymmetric key transport.

FIGURE 2.16 Asymmetric man-in-the-middle (MITM) key transport.

Cryptography Basics 29

The sender generates a random symmetric key, encrypts it using the interloper’s public key
believing it was the receiver’s public key, and transmits the ciphertext to the receiver. The ciphertext
is intercepted and decrypted using the interloper’s private key. At this point, the interloper now has
a copy of the symmetric key. Using the receiver’s public key, the interloper might re-encrypt the
symmetric key or generate and encrypt another symmetric key, and then forward the ciphertext onto
the receiver. Regardless, the receiver decrypts the ciphertext using its private key to recover the
symmetric key. The sender and the receiver are under the false impression that they have securely
exchanged a symmetric key without realizing the interloper is in the middle eavesdropping on any
and all encrypted communications.
Figure 2.17 depicts a simplistic view of establishing a symmetric key without using key trans­
port. Each party has its own asymmetric private key and public key certificate. The two parties
must also exchange certificates. In general, each party using their own asymmetric key pair, and the
public key of the other party, can mathematically compute a common shared secret from which a
symmetric key is derived. The shared secret cannot be computed without access to one of the private
keys. Thus, the symmetric key is not actually exchanged between the two parties. Examples of key
agreement methods include Diffie–Hellman [B.1.5] based on the original paper “New Directions in
Cryptography” [B.7.6], published in 1976, and elliptic curve cryptography (ECC) schemes [B.1.10]
based on the papers “Uses of Elliptic Curves in Cryptography” [B.7.7] and “Elliptic Curve Crypto­
systems” [B.7.8] independently authored two years apart.
The details of the key agreement process will vary depending on the algorithm employed. Some
algorithms only require the private key of one and the public key of the other. Other algorithms use
the key pair of one and the public key of the other. Yet others allow ephemeral key pairs, generated
temporarily to increase the overall entropy of the symmetric key. In addition to the asymmetric
keys, there are also domain parameters and other values that both parties need to agree upon for the
crypto mathematics to operate successfully. These details are beyond the scope of this book but are
available in various standards [B.1.5], [B.1.6], and [B.1.10] and specifications.
What we can say about symmetric and asymmetric keys is that there are security controls that
must be in place in order for the overall system to be considered trustworthy. In general, we can treat
symmetric keys and asymmetric private keys in a similar manner utilizing strong security controls
around protecting the confidentiality of these keys. Note that asymmetric public keys have different
requirements. We can summarize the primary key management controls: key confidentiality, key
integrity, key authentication, and key authorization.
Key confidentiality: Symmetric and asymmetric private keys must be kept secret. Unlike data
confidentiality where authorized entities are permitted to know the information, keys cannot be
known by anyone. The primary key confidentiality control is the use of cryptographic hardware
modules discussed in Section 2.5, “Cryptographic Modules.” Some folks dispute this rule, claiming

FIGURE 2.17 Asymmetric key agreement.

30 Security Without Obscurity

that key owners or system administrators are “authorized” to see or know keys; however, controls
intended to prevent unauthorized access can fail, be circumvented, or individuals can be coerced.
The better approach is to manage symmetric and asymmetric private keys such that they are never
stored or displayed as cleartext. We summarize the key confidentiality controls as follows:

1. Symmetric keys and private asymmetric keys are used as cleartext inside cryptographic
hardware modules but are not stored as cleartext outside the crypto module.
2. Symmetric keys and private asymmetric keys are stored as ciphertext outside crypto­
graphic hardware modules.
3. Symmetric keys and private asymmetric keys are stored as key splits outside crypto­
graphic hardware modules, managed using dual control and split knowledge. Each key
split is managed by different individuals under supervision by a security officer to avoid
collusion between the individuals.

It is important to recognize that key confidentiality does not apply to asymmetric public keys as
knowledge of the public key does not reveal any information about the corresponding private key.
Thus, the strength of PKI is that anyone can use the public key without endangering the security of
the private key.

Key integrity: The integrity of any key must be maintained, including symmetric keys, asym­
metric private keys, and asymmetric public keys. Controls must be in place to prevent the
modification or substitution of any cryptographic key. More importantly, controls must
also be in place to detect any adversarial or inadvertent modification or substitution. Any
unintentional change must return an error and prevent the key from being used.
Key authentication: The authenticity of any key must be verified, including symmetric keys,
asymmetric private keys, and public keys. Controls must be in place to prevent any illicit
keys from entering the system. In addition, systems must have the capability to validate
the key. Any failed validation must return an error and prevent the key from being used.
Key authorization: The use of symmetric and asymmetric private keys must be restricted to
authorized entities. For example, individuals enter passwords to unlock keys, or applica­
tions are assigned processor identifiers with access to system files. Any unauthorized
attempts must return an error and either trigger an alert for incident response or prevent
the key from being used after some number of maximum attempts.

All four of these principal controls apply to the overall key management lifecycle. There are
many key management models defined in many standards and specification, but for the purposes
of this book, we refer to the American National Standard for PKI Asymmetric Key Management
[B.1.14] depicted in Figure 2.18. The lifecycle is represented as a state transition diagram with seven
nodes: key generation, key distribution, key usage, key backup, key revocation, key termination,
and key archive. The lifecycle is applicable for symmetric and asymmetric keys. The number of

FIGURE 2.18 Key management lifecycle.

Cryptography Basics 31

transition arrows has been simplified for our discussion. Depending on the application environment
and events that drive the transitions, the cryptographic key state might not occur in every node.

Key Generation: This is the state when and where keys are generated for a specific purpose.
Symmetric keys are basically random numbers, but asymmetric key pairs are more complex,
incorporating random numbers and prime numbers in their creation. Keys might not be gener­
ated at the location or in the equipment they are to be used, and therefore might be distributed.
Key Distribution: This is the state when keys are transferred from where the keys were
generated to the location or equipment where the keys are to be used. The distribution
method might be accomplished using manual or automated processes, and depending on
the method might occur in seconds, hours, or days.
Key Usage: This is the state when and where the keys are used for their intended purpose
as an input into the cryptographic function. The key usage occurs within a cryptographic
module that might be software or hardware, as discussed in Section 2.5, “Cryptographic
Modules.” In addition, the keys might be backed up and recovered to maintain system
reliability.
Key Backup: This is the state when and where the keys are backed up for recovery purposes
when the keys in use are inadvertently lost. When the keys are backed up they are often
distributed from the usage to the backup locations, and when keys are recovered they are
again distributed from the backup to the usage locations. Keys might also be backed up
during distribution from generation to usage.
Key Revocation: This is the state where keys are removed from usage before their assigned
expiration date due to operational or security issues. Operational issues include service
cessation, merger, acquisition, or product end of life. Security issues include known or
suspected system hacks, data breaches, or key compromises.
Key Termination: This is the state where keys are removed from usage or revocation when
reaching their assigned expiration date. Essentially, every instance of the key is erased
from all systems, including key backup, with the special exception of key archival.
Termination might take seconds, hours, days, or longer to securely purge all key instances.
Key Archive: This is the state when and where keys are stored beyond their usage period
for purposes of post-usage verification of information previously protected with the key.
Archived keys are never reused in production systems but rather they are only utilized in
archival systems.

Note that key escrow is not shown in Figure 2.18. Key escrow is a term borrowed from money
escrow where funds are held by a third party for future dispersals such as mortgage insurance or
property taxes and from software escrow where the source code is held by a third party in the event
the provider goes bankrupt. Key escrow is the practice of storing keys for the explicit purpose of
providing them to a third party. Third-party examples include government regulations, law enforce­
ment in the event of a subpoena, or other legal obligations. In practice, key escrow is rarely used,
and it would not be an independent key state, rather it would more likely be part of key backup or
key archive to meet whatever escrow requirements might be imposed on the organization.
Now let’s turn our attention to key management lifecycle controls. There are many standards and
other resources that discuss key management controls in minute detail. It is not the intent of this
book to reiterate what is already available. However, for continuity with later chapters, Table 2.3
provides a summary of controls. Each of the controls is discussed in more detail with references to
relevant standards.
Crypto software: This control refers to cryptographic software modules that are basically soft­
ware libraries that specialize in performing cryptographic functions that are accessible using cryp­
tographic application programming interfaces (crypto API). Some operating systems provide native
cryptographic capabilities, some programming languages provide additional cryptographic libraries,
32 Security Without Obscurity

TABLE 2.3
Key Management Lifecycle Controls
Cryptographic Key Management Controls
Key Key Key Key Key
Lifecycle Confidentiality Integrity Authentication Authorization
Key Crypto software Key fingerprint Originator ID Access controls
Generation Crypto hardware Certificate
Key Key encryption Key fingerprint Originator ID Access controls
Distribution Crypto hardware Certificate Dual control
Key splits Split knowledge
Key Key encryption Key fingerprint Source ID Access controls
Usage Crypto software Certificate Requestor ID
Crypto hardware
Key Key encryption Key fingerprint Source ID Access controls
Backup Crypto hardware Certificate Dual control
Key splits Split knowledge
Key Key encryption Key fingerprint Requestor ID Access controls
Recovery Crypto hardware Certificate Dual control
Key splits Split knowledge
Key Key encryption Key fingerprint Source ID Access controls
Revocation Crypto software Certificate Dual control
Crypto hardware
Key splits
Key Key encryption Key fingerprint Source ID Access controls
Termination Crypto software Certificate Dual control
Crypto hardware
Key splits
Key Key encryption Key fingerprint Source ID Access controls
Archive Crypto hardware Certificate Dual control
Key splits

and some systems need to incorporate third-party cryptographic toolkits. Cryptographic software
modules are discussed in Section 2.5, “Cryptographic Modules.”

Key encryption: This control refers to the storage or transmission of cryptographic keys as
ciphertext. The cryptographic keys are encrypted using a key encryption key (KEK).
KEKs are used solely to encrypt other keys; they are never used for any data functions
such as data encryption, MAC, HMAC, or digital signatures. Key encryption is used for
storage or transmission of other keys as ciphertext that provides key confidentiality.
Crypto hardware: This control refers to cryptographic hardware modules that consist of soft­
ware, firmware, and hardware components that specialize in performing cryptographic
functions accessible via API calls. Application developers incorporate cryptographic
hardware modules, commonly called hardware security modules (HSMs), from ven­
dors who manufacture cryptographic devices. Note that HSM vendors undergo merg­
ers and acquisitions just like any other technology industries with products that suffer
end-of-life time frames. Cryptographic hardware modules are discussed in Section 2.5,
“Cryptographic Modules.”
Key splits: This control refers to various techniques for dividing up keys into multiple parts.
One common method is key components, and another is key shares. We use the term
“splits” to refer to either method. Key splits provide key confidentiality.
Cryptography Basics 33

Key components: This method uses the binary operator “exclusive or” often denoted by the
abbreviation XOR or the ⊕ symbol. In general, 2 bits are combined such that if they are
the same, the result is a binary 0; otherwise, if they are different, the result is a binary 1,
that is: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1, and 1 ⊕ 1 = 0. For example, two individuals can
each have a key component that is a binary string such that neither knows the other’s key
component, but when the two strings are combined using XOR, a key is formed. Knowing
a bit in one string but not knowing the corresponding bit in the other string does not reveal
any information about the bit in the key.

Key components can support any number of strings but to recover the key, all of them must be
available. For instance, if the key is split into five key components where each is assigned to differ­
ent individuals, then all five key component holders are needed to recover the key.
In practice, key components are typically written on paper and kept locked up by the key com­
ponent holder (also called a key component custodian). Unlike passwords, key components are too
long for an average person to remember. For example, using hexadecimal notation an AES-128 key
component might be:

c7e2 f303 878a5 22d7 ef46 4ab0 317b dbe9

where each “hex” digit represents 4 bits. The key component is entered manually by each compo­
nent holder, outside the view of the others, until all of the components have been entered. The key
components are then locked up securely. This key management process is often supervised by a
security officer and sometimes observed by an auditor [B.1.2].
Key shares: This method uses an algebraic equation, such as Shamir’s Secret Sharing [B.7.9] such
that the key is divided into M parts but only N parts are needed to recover the key. This is called an N
of M scheme, where N < M. For example, 3 of 7 might be chosen where the key is divided into M = 7
parts and assigned to seven individuals, where only N = 3 individuals are needed to recover the key. The
formula to calculate N possible combinations from M available individuals is M!/N! (M − N)! where
“!” is the factorial function. So, for N = 3 and M = 7, we have 7! = 7 × 6 × 5 × 4 × 3 × 2 × 1 = 5040 and
3! = 3× 2 × 1 = 6 so (7 − 3)! = 4 × 3 × 2 × 1 = 24 such that 5040/(6 × 24) or 5040/144 = 35 possible com­
binations. Thus, there are 35 ways for 3 of 7 key shares to recover the key. Unlike key components, key
shares are large numbers that are too big to use paper, so it is a common practice for the key shares to be
written to removable media where each device is assigned to a key share holder. The devices are often
PIN activated such that mere possession is insufficient to enter the key share. Each device is inserted
into a device reader that uses the key shares to solve the equation and recover the key.
Key fingerprint: This control is a generic term that refers to a cryptographically derived check­
sum that provides a relatively unique reference value per key. Fingerprints provide key integrity and
a means to verify a key value without having to display the actual key.

• For symmetric keys, the historical method is a key check value (KCV) that is created by
encrypting a string of binary zeroes and commonly using the leftmost six digits as the
KCV [B.1.2].
• For asymmetric keys, the common method is a hash of each key, one for the public key
and another for the private key. Note that the key fingerprint algorithm may differ per
vendor or crypto product but SHA1 is commonly used. Regardless of the algorithm, the
key fingerprint can be used to verify the key stored in an HSM or when using key splits.
The recovered key might have a fingerprint as well as each key split.

Certificate: This control refers to digital certificates introduced in Section 2.2, “Authentication.”
As discussed earlier, the certificate signature is over all of the certificate fields, which provides
cryptographic bindings between the sender’s name, public key, and the CA name. The certificate
34 Security Without Obscurity

provides integrity of the public key. Certificates can also have a fingerprint, called a thumbprint,
which is a hash of the whole certificate, including its digital signature.

Originator ID: This control refers to the key generation system. Tracking the origin of the key
helps to maintain the overall system authentication.
Source ID: This control refers to the key usage system. Tracking the source of the crypto­
graphic function and the associated key helps to maintain the overall system authentication.
Requestor ID: This control refers to the application accessing the cryptographic function.
Tracking which requestor accessed the cryptographic function and the associated key
helps to maintain the overall system integrity.
Access controls: These controls refer to the permissions granted to the originator, source, and
requestors. Requestors include applications, end users, and system administrators. Access
controls restrict who can perform key establishment, key installation, key activation, key
backup and recovery, key revocation, key expiration, rekey, key archive, and other cryp­
tographic functions.

Dual control with split knowledge: This control refers to the use of key splits for key distribution
or key backup and recovery. Assigning different splits to different individuals is the essence of split
knowledge, as no one person knows the value of the actual key. Requiring more than one person for
a cryptographic function is the basis for dual control.
Certificate management is a subset of key management and follows the same patterns shown in
Figure 2.18. The certificate contains information about the public key and indicates information
about the corresponding private key. In addition to the certificate fields listed in Table 2.2, there
are other basic certificate fields and certificate extensions. Another important certificate field is the
validity element, which contains the start “not before” and end “not after” dates. Figure 2.10 shows
how to walk up the chain and verify each certificate coming down the chain, but in addition, the
validity dates of each certificate must also be checked. If the current date is not between the start
and end dates, then the validation fails. Thus, the application performing the validation must be
cognizant of the current date and time with an accurate clock.
The certificate extensions are related to X.509 v3 format. Each extension has an object identifier
(OID), which asserts its presence, and the corresponding content. Other essential fields are the cer­
tificate revocation list (CRL) distribution points and authority information access extensions. The
CRL extension provides a link to the CRL, and the authority extension provides a link to the Online
Certificate Status Protocol (OCSP) service. If a certificate is revoked prior to its expiration not after
date, the CRL or an OCSP responder provides a mechanism to check the certificate status. If any of
the certificates within the chain have been revoked, then the validation fails.

2.5 CRYPTOGRAPHIC MODULES

The concept of a cryptographic module was introduced in Section 2.2, “Authentication,” and Sec­
tion 2.4, “Key Management,” where differences between software and hardware modules were
identified. NIST operates the Cryptographic Module Validation Program (CMVP) based on the
Federal Information Processing Standard (FIPS) 140 revisions (140, 140–1, 140–2, and 140–3),
which 140–2 [B.5.3] provides the current definitions:

• Cryptographic module: The set of hardware, software, and/or firmware that implements
approved security functions (including cryptographic algorithms and key generation) and
is contained within the cryptographic boundary.
• Cryptographic boundary: An explicitly defined continuous perimeter that establishes the
physical bounds of a cryptographic module and contains all the hardware, software, and/
or firmware components of a cryptographic module.
Cryptography Basics 35

FIPS 140 was redesignated in April 1982 from Federal Standard 1027 General Security Require­
ments for Equipment Using the Data Encryption Standard. This standard specified the minimum
general security requirements for implementing the Data Encryption Standard (DES) algorithm
[B.5.1] in a telecommunications environment.
FIPS 140–1 was revised in January 1994 and renamed Security Requirements for Cryptographic
Modules. This standard introduced four security levels from lowest to highest: level 1, level 2, level
3, and level 4. This version became effective six months later, in June 1994, and the previous version
was deprecated three years afterward, in June 1997.
FIPS 140–2 [B.5.3] was revised in May 2011, which became effective six months later, in Octo­
ber 2011, and the previous version was deprecated six months afterward, in March 2012. Products
certified per FIPS 140–1 were moved to a historical list.
FIPS 14–3 [B.5.36] was revised in March 2019, which became effective six months later, in
August 2020, and the previous version was deprecated six months afterward, in January 2021. This
version refers to ISO/IEC 19790 [B.4.12] and ISO/IEC 24759 [B.4.13]. Products certified per FIPS
140–2 were moved to a historical list.
While there are international and country-specific standards and validation programs, for the pur­
poses of this book, we refer to FIPS 140–3 as the de facto standard. This is a common approach sup­
ported by many others. Another recognized standard is the Common Criteria transformed into ISO/IEC
15408 Information Technology – Security Techniques – Evaluation Criteria for IT Security [B.4.7],
but this standard provides a security language to develop either security targets or protection pro­
files (PPs) for laboratory evaluations. Examples include the German cryptographic modules, security
level “enhanced” [B.7.10], and the European Union cryptographic module for CSP signing operations
[B.7.11]. For the financial services industry, there is also ISO 13491 Banking – Secure Cryptographic
Devices (Retail), but unlike the CMVP, there is no corresponding validation program. Regardless,
FIPS 140–3 defines four security levels (level 1 is the lowest) with 11 distinct security areas.

SPECIAL NOTE 2‑2 SECURITY LEVELS

It is a common misconception that cryptographic hardware modules are automatically rated
at higher levels 4 or 3, as many hardware modules are actually rated at software levels 2 or 1.

For example, the August 2015 CMVP list has over 2,200 product certificates issued by NIST to more
than 400 manufacturers. FIPS 140–2 Security Levels 1 and 2 were designed for software modules,
whereas levels 3 and 4 were designed for hardware modules. Roughly 67% of the products are listed as
hardware, 29% as software, and 3% as firmware. However, only 1% of the hardware modules are rated
at level 4 and 26% are rated level 3; 61% are rated at level 2 and 12% are rated at level 1. Thus, the
majority 73% of cryptographic hardware modules are rated at a security level typical of a cryptographic
software module. The reader should always check the security level of the FIPS certification.
The previous edition of this book discussed the FIPS 140–2 security areas, and while this edition
discusses the FIPS 140–3 security areas, the ISO/IEC 19790 international standard has reorganized
the security areas. Table 2.4 provides a summary comparison between the FIPS 140–2 versus the
FIPS 140–3 security areas.
The following chapters provide a summary for the 11 FIPS 140–3 security areas.

2.5.1 cryptoGrAphic Module SpeciFicAtion

Most HSMs have different operating modes, and how they are operated determines the actual FIPS
140–2 security level at which they are certified. Each cryptographic module certification includes a
vendor-provided security policy that defines the configuration and the operating mode. Note that using a
Random documents with unrelated
content Scribd suggests to you:
 — Siellä se on koti, missä leipäkin, — sanoi Aku hymyillen.

— Oletko perheellinen mies? — kysyi Anni.

— En maar, sentään, — tokaisi Aku hämillään.

— Mitä merkillistä sekään olisi noin pulskan miehen! —

— No, Anni, — varotti Liina.

— Höm. Kuinka kauan olet ollut täällä? —

— Pari viikkoa. —

— Emmekä ole ennen sattuneet tapaamaan! —

— Olen minä nähnyt, vaan en arvannut tulla lähemmäksi. — Akun

katse sattui Liinaan samalla kun tämä kiinnitti häneen suuret,
salaperäiset, hymyilevät silmänsä ja he punastuivat kumpikin.

— Mitä sinä pelkäsit? kysyi Anni.

— Te olette niin muuttuneet. —

— Niinhän sinustakin on tullut mies ja — — — Anni keskeytti

lauseensa, sillä Aku ei näyttänyt kuuntelevan hänen sanojansa,
katseli vaan Liinaa, joka käytävän ahtauden vuoksi astui heidän
edellään.

Lapsuuden toverin näkeminen palautti Annin, niinkuin hänen

ystävänsäkin, mieleen ne muistot, jotka selvinä kuvina sinne olivat
painuneet; mutta Anni ei tiennyt, että Akun ja Liinan sydämissä asui
rikkaampia ja rakkaampia kuvia, joihin ei hänellä mitään osaa ollut.
 — Muistatkos niitä kansakoulun aikoja? — jatkoi Anni, — kun me
asuimme Armonkalliolla ja olimme talosilla, me kolme aina yhdessä.
Sinä, Aku, olit herra, muka, kävelit tikku hampaissa ja kädet
housuntaskuissa. Liina oli rouva, muistatkos sinä, kun pitelit
lepänoksaa pääsi päällä suojana, se oli muka päivänvarjo, ja puhuit
jotakin sekamelskaa, ruotsia, näes. Ja minä, tietysti minä olin piika.
— Anni nauroi herttaisesti.

— Se talosilla olo sai surkean lopun, — sanoi Aku muuttuen äkkiä

synkän näköiseksi.

— Niin, sinähän löit kuoliaaksi Helmiskän porsaan, kun se tuli

meidän koppiamme tonkimaan, eikä se muija antanut meille
pahaakaan rauhaa sen jälkeen. Äitisikin muutti sitten pois. —

— Älä puhu, — kuiskasi Liina Annin korvaan, mutta Aku kuuli sen
ja katsoen Liinaan hän sanoi:

— Ne ajat ovat elävänä kuvana minun mielessäni; varsinkin se

junalta tulo. —

— Mikä se sitten oli? Siitä en minä tiedäkään, — sanoi Anni

vilkasten Liinaan; mutta hän oli kuin suljettu kirja, katsoi vaan
eteensä käytävälle.

Anni ei jatkanut keskustelua, sillä vaistomaisesti hän aavisti Akun

mielialan. Akun isä oli ollut rajuluontoinen ja juovuspäissään
tappanut miehen. Anni muisti vielä, miten katupojat huutelivat
Akulle: — murhaajan poika! —

Seuraavina iltoina, kun nuoret tapasivat toisensa, olivat entisyyden

ikävät muistot haihtuneet. He elivät nykyisyydessä syttyen uusiin,
voimakkaisiin tunteisiin, jotka kohtalon voimalla määräsivät heidän
vastaisen elämänsä juoksun.

Anni muuttui vähitellen iloisesta umpimieliseksi. Toisinaan hän

tokaisi jonkun purevan sanan, jotta Liina hätkähtäen katsoi Akuun,
jonka tulinen silmäys ajoi punan hänen poskillensa. Liina tunsi aina
sen katseen suojassa suurta turvallisuutta ja samalla salaista
yhteyttä lapsuuden toveriin.

Eräänä sunnuntaiaamuna koputettiin Liinan ovelle ja Aku astui

sisään hymyillen hämillänsä.

— Etkö lähtisi kävelemään, Liina? —

— Onko Annikin tullut? — kysyi Liina ollen ikäänkuin Anniin kiinni

kasvanut sen jälkeen kun Paavo hänet jätti. Akun kanssa
kahdenkesken olo tuntui hänestä luonnottomalta; mutta Aku oli
päättänyt olla rohkea.

— Ei ole, mennään kahden vaan, — sanoi hän varmasti. Se

vaikutti. Liina sitoi huivin päähänsä, otti nisuleipää evääksi ja kahden
he lähtivät sunnuntaikävelylle.

— Minne menemme? — kysyi Liina.

— Kauas. —

— Kuinka kauas? —

— Metsään. —

— Mennäänpä sinne mökille! — huudahti Liina äkillisen mieliteon

valtaamana.
 — Sinne minäkin tarkoitin. Olisin vaan tahtonut viedä sinut
lähemmäksi, kunnes olisit arvannut. —

— Vieläkö se mummo mahtaa elää? —

— Hän olisi jo hyvin vanha. —

— Muistatko sinä niitä aikoja? — kysyi Liina uneksiva ilme

kasvoillaan.

— Muistan kyllä. Kaikki minä muistan, varsinkin päivän, jolloin

mökkiin muutettiin. Samana päivänä vietiin isäni raudoissaan
asemalle. Hän laahusti raskaasti jalkojaan ja kahleet kalisivat ja
Helmiskä huusi ilkeästi: — Seppä on takonut itselleen kovat ketjut.
— Sinä sanoit Helmiskälle: — Eipäs, pahat ihmiset ne panivat Akun
isän jalkoihin. — Minä tartuin sinun käteesi ja yhdessä me
marssimme sitten Armonkalliolle. Kun pojat taas huutelivat: —
murhaajan Aku! — otin minä nyrkin kokoisen kiven ja aijoin heittää
irvistelijöihin; mutta sinä tartuit käsivarteeni ja vaarallinen kivi putosi
sivullemme. Tämän sinä kyllä muistat! — puhui Aku hellästi
silmäillen lapsuuden ystävää, kiitollisena siitä, että sai täyttä
sydäntään tyhjentää silmin nähneelle ja sydämin tunteneelle
toverilleen.

— Muistan kyllä, ja senkin, kun yhdessä äitisi kanssa juoksimme

tätä polkua ja keräsimme käpyjä minun helmaani lehmiksi uuteen
taloomme. Sinne ei pitänyt Annin päästä, sillä hänkin oli sanonut —
muistatko? — Aku nyökäytti päätään ja Liina puhui iloisesti, vastoin
tavallisuuttaan vapautuneena kainoudestaan ja
harvasanaisuudestaan.
 Aurinko välkehti lehtopolulla taittaen säteensä korkeitten honkien
kellertäviin kylkiin. Metsän hiljainen humina säesti lapsuudenystävien
muistoja, jotka unesta heränneinä kuiskivat kiviltä ja mäiltä.

— Katsos, tuon kivenkin minä muistan, — sanoi Liina. — Tässä me

auringon paahteessa nukuimme odottaessamme äitiäni, joka ei
koskaan tullut. —

— Muistanhan minä. Sinä nukuit itkien minun syliini. —

— Et sinä aavistanut, kuinka minä silloin kaipasin omaa äitiä. Minä

häpesin, niin, se oli kauhea häpeä, ettei minulla ollut äitiä niinkuin
toisilla lapsilla. Olisinhan minä isänkin mielelläni pitänyt, niinkuin
Annilla oli, ja sitten olisin kovin juhlallisesti tahtonut sanoa: — äiti on
kuollut. — Sinua minä usein kadehdin. Kun äitisi toi rievää ja antoi
sinulle, olin oikein vihainen äidillesi. Kyllä hän aina antoi minullekin,
mutta minä olisin tahtonut saada omalta äidiltäni. —

He olivat saapuneet varsinaiseen metsään, jossa lehtevät koivut ja

lepottavat haavat huokasivat syvään, ikäänkuin Liinan kertomus olisi
herättänyt niissä myötätuntoa. Nuoret kääntyivät katsomaan
astumaansa tietä kaupungin puiston korkeitten honkien suojassa.

— Muistatko vielä, kuinka me täällä polulla rukoilimme, että

Jumala lähettäisi äitini tänne Lepolan mummon mökille. Olihan
mummo vakuuttanut, että Jumala kuulee. Tässähän me odotimme.
—

— Tiedätkö, mitä minä rukoilin? Mahdottomuuksia. Minä rukoilin

isäni vapaaksi pääsemistä ja sen teon olemattomaksi julistamista.
Sitten odotin monet ajat isää kotiin, vaan kun ei häntä kuulunut,
rupesin minä pelkäämään. Se jokin, se pahansuopa voima, joka oli
isänikin vienyt, se vaani minua joka kiven ja kannon takana, puun
juurilla ja pimeässä viidakossa. Tuskin uskalsin päivällä olla yksinäni.
Toisinaan se ahdisti minua unissakin ja minä painiskelin sen kanssa
ja huusin raivoisasti, kunnes heräsin omaan huutooni. Vielä nytkin
tulee joskus tuo uni minua vaivaamaan. —

— Katsos, tuollahan mökki onkin! Voi, kuinka se on pieni ja

matala.
Oliko se silloinkin noin pieni? Ei, Aku, olihan se paljon suurempi.
Nuo rikkinäiset ruudut ja rääsyt akkunassa sen noin rumaksi tekevät.
Mennään sisään. —

— Ei tänne pääse. Ovi on lukossa, — sanoi Aku ovea ryskyttäen.

— Katsotaan akkunasta. Minä tahtoisin nähdä pesän ja pöydän ja

hyllyn ja sängyn, missä mummon kanssa nukuin. Tehän makasitte
lattialla. Kuule, nosta minua hiukan, hiukan vaan! —

Kurjan, matalan mökin nähdessään unohtivat lapsuudenystävät

koko maailman. Tämän yhteisen kodin seinuksella he olivat
sisaruksia. Täällä he olivat isättömänä ja äidittömänä löytäneet
turvan, piiloutuneet maailmaan pilkalta ja häpeältä, joka jo aikaisella
iällä oli heihin ilkeät nuolensa ampunut ja opettanut kiihkeästi
kaipaamaan sitä, mikä kaikille lapsille on siunatun, onnellisen elämän
ehto, kodin rauhaa ja rakkautta. Vieläkin täytti sama kaipuu heidän
sydämensä ja he vapisivat kiitollisuudesta seistessään tämän kurjan
asumuksen luona, joka kerran oli heille edes hiukan kodintunnetta
suonut ja vieläkin seisoi heidän pyhien lapsuusmuistojensa
todistajana.

— Ei siellä ole muuria eikä sänkyä eikä pöytää eikä lattiaakaan! —

huudahti Liina masentuneena. — Se on tyhjä, ihan tyhjä! Miksi he
ovatkin sen paljaaksi raastaneet? Miksi emme tulleet tänne
ennemmin? — Liina peitti kasvonsa ja itki hiljaa, niinkuin itkee
vanhan ystävän kuolemaa.

Aku silitteli hänen päätään eikä hennonnut puhua. Siinä he

aurinkoisella seinustalla seisoivat, kuten ennen lapsina talosilla
ollessaan. Se hetki sitoi heidät muistojen kaihoisella rauhalla.

— Tässä on niin hyvä olla, — sanoi Aku, yhä pidellen Liinaa

kädestä.

— On. —

Mutta todellisuus nousi varmasti kuin usva kosteasta maasta

heidän rauhoitettuihin sydämiinsä; ja usvan haihtumista seurasi
paahteinen keskipäivän aurinko. Se poltti hehkuvana tulena Akun
tulisessa katseessa ja tunkeutui huumaavana lämpönä Liinan
sydämeen.

Liina veti hiljaa kätensä pois Akun kädestä ja astui metsäpolulle,

josta olivat tulleet.

— Joko mennään, — sanoi Aku seuraten varjona Liinan liikkeitä.

— Mennään; tämä on pyhä paikka. — Hän olisi tahtonut juosta ja

huutaa apua, niin vaaralliselta ja lumoavalta täällä olo tuntui.

— Älä pelkää, — kuiskasi Aku. — Minä tiedän, mitä ajattelet, vaan

sinä olet minulle pyhempi kuin sisar. — Raivoisa tuskan puuska
puristi nyyhkytykset miehen rinnasta. — Minä tunnen nyt jo, ensi
kertaa kahden ollessamme, kuinka kalliisti saan ostaa nämä tunnit!
—
 Liina seisoi vavisten hänen vieressään ja tunsi ruumiillista kipua
Akun nyyhkytyksistä. Hän sai ponnistaa kaikki voimansa
pidättääkseen kättänsä koskettamasta Akun kumaraista, paljastettua
päätä.

— Älä luule, Liina, että olen pahoillani, vaikka näit minun itkevän.
Minulla ei ole koskaan ollut näin hyvä kuin nyt. Me tulemme sen
kautta lähemmäksi. —

— Älä puhu, — keskeytti Liina hätäisesti.

He astuivat hiljaa, varovin askelin kuin pyhässä temppelissä.

Metsän hyminä oli kuin hartaitten huokaukset.

Entisyyden todellisuus haihdutti lumouksen, ja Aku alkoi kertoa

menneisyydestä. Paluumatka mökiltä johdatti hänen mieleensä ne
ajat, jolloin hän äitinsä kanssa sieltä lähti.

— Käsikärryillä vedimme tavaramme tätä tietä kaupunkiin. Minä

pääsin kouluun. Ensimmäisen todistuksen saatuani kaipasin sinua.
Olisin tahtonut näyttää sen sinulle, niin komea se oli, vaan en tiennyt
missä silloin olit. —

— Muistin minäkin sinua. Toverit osoittivat minua sormellaan ja

sanoivat: — toll' ei oo isää! — ja joku vielä lisäsi: — ja äiti
hongottaa! — Minua hävetti, niin että ratkesin suureen poruun.
Opettaja sattui paikalle ja sanoi: — Ei saa Liinaa kiusata. Hän on
orpo. — Jos hän olisi sanonut minua kreivittäreksi, en olisi voinut olla
ylpeämpi. Silloin muistin sinua: — ei Akukaan tainnut tietää, että olin
orpo, — ajattelin. Annille kerroin heti, mitä opettaja oli sanonut. Me
olimme silloin hyvät ystävät ja asuimme samalla suunnalla. Hän oli
isänsä luona ja minä talonomistaja Latosella. Minulla oli kylläkin hyvä
olla. Esimies kävi toisinaan katsomassa ja hänellä oli lempeät silmät.
Usein kuitenkin itkin ja odotin äitiäni. Luulin suureen tyttöön saakka,
että hän olisi nuori, kaunis nainen. Kun kadulla näin hyvännäköisen
ihmisen, niiasin syvään ja sydämeni pamppaili: — voisihan tuokin
olla äitini, — ajattelin.

— Etkö ole koskaan äidistäsi kuullut? —

— Olen, — sanoi Liina empien, mutta samassa hän katui

umpimielisyyttään. — Kuulin hänen kuolleen mielipuolena maalla,
saunan seinään kytkettynä.

— Loppusanat hävisivät kuiskaukseen, eikä kumpikaan puhunut

hetkeen aikaan.

Metsän humina kuiskaili heille, miten mitätön on ihminen kohtalon

kovissa käsissä. Heidän oma pienuutensa, suuren luonnon sylissä,
pakotti heidät arasti ajattelemaan olemustansa.

— Liina, — sanoi Aku, katse yhä polkuun kiinnitettynä. — Minusta

tuntuu kuin ei tämä ruohoinen polku astuessamme etenisi; me vaan
survomme aina samaa paikkaa. Samanlaista on minusta elämämme.
Me emme ole vieläkään irtaantuneet lapsuuden tunteista; ne ovat
vaan toisessa muodossa mielessämme. — Hetken kuluttua hän äkkiä
kysyi:

— Uskotko, että Jumala etsiskelee isäin pahat teot kolmanteen ja

neljänteen polveen? —

— Minä en uskalla ajatella sellaisia asioita, sillä jos hetkeksikään

annan niille valtaa, kauhistun niitä ja minusta tuntuu kuin joku
tarttuisi minuun. Ja se joku on aina paha voima, — puhui Liina
salaisen ahdistuksen painostamana.

— En minäkään tahtoisi näitä ajatella, vaan minun täytyy. — Akun

katse oli jännitetty ikäänkuin torjumaan näkymätöntä vihollista.

Liina katsoi häneen säikähtänein, suurin silmin.

— Toisinaan joudun ihan raivoon ajatellessani, että isäni teki sen

ja jätti minulle kamalan muiston kalisevista raudoistansa. Vanhat
koulutoverini, joita on täällä konepajassakin, muistavat vielä kaiken
tuon. Heidän sivuuttavat katseensa saavat sappeni kuohumaan, kun
vaan kiistaan joudutaan. Ja jos he uskaltaisivat viitata siihen, en
tiedä, mitä tapahtuisi.

— Jumalan tähden, Aku, älä puhu noin! Sinä et saa miettiä

sellaisia asioita. Ole iloinen, kuule, ajattele muita asioita, jotakin —
— —! —

— Liina, — keskeytti Aku tarttuen hänen käteensä, — jos sinä

olisit minun, unohtaisin isäni; mutta sinä et ole! Minä olen yksin, eikä
kukaan minusta välitä! —

— Minä välitän! —

— Sinä välität; mutta sinulla on mies. Ja jos sinä uskallat välittää

minusta, saat saman maineen kuin oli äidilläsi. Niin, sinäkin olet äitisi
tytär, heikko ja taipuvainen, vailla rautaa. Miksi sinä menitkin tuon
puskevan pässin vaimoksi? Voitko sinä selittää sitä? — Akun katse oli
muuttunut uhkaavaksi. Liina väänteli käsiään ja purskahti itkemään.
— Se on totta, voi äiti, äiti! — Liina istui kivelle ja nyyhki kauan
aikaa.
 — Heikkoja ei säälitä, ne viskataan lokaan! Kun ajattelen äitiäsi,
vapisen sinun puolestasi, ja se saattaa minut raivoon. Jos näkisin
jonkun miehen sinuun koskevan, niin — —! —

— Aku kulta, älä puhu noin, minä pelkään sinua. — He astuivat

edelleen. — Jos kirjoittaisin Paavolle ja pyytäisin eroa. Silloin
olisimme vuoden päästä — — Liina vaikeni ja katse leimahti kuin
keväinen päivä pilven lomasta. Aku pysähtyi ihaillen hänen hentoa
kauneuttaan.

— Tahtoisitko sinä? —

— Tahtoisin. —

— Tällä viikolla voimme jo saada tiedon. —

— Niin. —

Päätös toi rauhan kummallekin. Levollisesti jutellen he saapuivat

Liinan asunnolle. Sovittuaan illallisesta yhtymätunnista kaivon luona,
lähti Aku kotiinsa.

Päivä oli mennyt metsässä yhtenä humauksena. Kello oli jo kuusi

Liinan kotiin tullessa. Kiireesti hän söi ja mietti samalla mitä
Paavolle kirjoittaisi. — Akusta ei mitään sanota, ei, ei vaikka.
Ettei rakasta, niin ettei rakasta. Paras on kirjoittaa, kuten sanat
sattuvat.

Hyvä Paavo!

Kai hyvin hämmästyt pyyntöäni, jonka sinulle esitän. Koska

näin erillään elämme, ajattelen, että meidän olisi parasta
erota. Ethän sinä suinkaan tahdo estää minua pääsemästä
 vapaaksi, kun nyt olen tullut huomaamaan tehneeni väärin
mennessäni sinun kanssasi naimisiin? Voithan sinä viipyä
siellä vuoden eteenpäin. Minä kuulutan sanomalehdissä.
Odotan vastaustasi hetimiten.

Liina.

Liina ei hetkeäkään ajatellut, että tällainen kirje vaikuttaisi

ärsyttävästi Paavon tapaiseen mieheen. Kun kirje oli laatikossa, tunsi
hän pistosta sydämessään. — Miten, jos hän olisi ollut Akun vaimo ja
Aku tahtoisi eroa. Nyt tuli sääli Akua, ikäänkuin hän jo olisi ollut
Akun vaimo.

Suihkun luona odottivat Anni ja Aku.

— Missä sinä, Liina, olet ollut tänään koko päivän? — kysyi Anni.
Liina vilkasi Akuun, vaan Aku ravisti päätään Annin takana.

— Enhän minä missään. Hiukan kävelyllä. — Liina piilotti hämillään

kasvonsa huiviin.

Samassa Anni kääntyi Akuun päin epäilevästi tuijottain häneen.

Aku osasi kuitenkin paremmin kuin Liina säilyttää salaisuuden. Anni
rauhoittui Akun suorasta silmäyksestä. He alkoivat kävelynsä
väkijoukossa, seuraten sen aaltoilua musiikin soidessa. Aku oli
tavattoman hyvällä tuulella, laski leikkiä Annin kanssa, samalla kun
hän salaperäisestä onnesta säihkyvin katsein seurasi Liinaa. Anni
muuttui illan kuluessa synkäksi.

— Mikä sinua vaivaa? — kysyi Aku tavantakaa, ja Anni tiuskasi:

— Mitä sinä minusta välität! —

 Äkkiä töytäsi juopunut mies joukosta heitä kohti, puhui rumia
sanoja ja kaappasi Liinan syliinsä. He olivat vähällä kaatua miehen
hoippuessa. Aku iski miestä nyrkillään, niin että hän, kädet leveällä,
kaatui kiviseen katuun. Nostettuaan hänet kevyesti kuin höyhenen
kauluksesta ylös, ravisteli Aku rauhan häiritsijää lyöden kerta
toisensa perään häntä poskelle. Kansaa kerääntyi ympärille ja poliisia
vihellettiin. Ennenkuin järjestyksen valvoja saapui, kuiskasi Anni
Akun korvaan:

— Varo itseäsi! — Aku laski heti uhrinsa. Anni ei käsittänyt, miksi

hänen sanansa niin äkkiä Akuun vaikuttivat. — Ehkä sentään Aku
hänestä piti. — Nyt hän taas liverteli. Mutta Liinan portilla hänen
lyhyt ilonsa sammui.

Unohtaen kaiken kysyi Aku:

— Kirjoititko? — sellaisella katseella silmäillen Liinaa, ettei Anni

enää voinut olla epätietoinen. Liina nyökäytti vastaukseksi päätään,
ja se nyökkäys selitti kaiken.

Liinasta erottua kysyi Anni:

— Mitä te kirjoittelette? —

— Emmehän me — —

— Pysy erossa Liinasta, hän on toisen muija! ärjäsi Anni nykäisten

Akua hihasta. Aku kiskaisi itsensä irti, kääntyi pois ja jätti hänet yksin
kotiinsa kulkemaan.

Anni puri hammastaan kiivaasti astuessaan. Huonetoveri oli jo

nukkunut ja Anni riisuutui nopeasti tuntien väsymystä. Sydän oli
kuitenkin liian täynnä; uni ei armahtanut tuskaista. Hän heittelehti
kuumalla vuoteellaan jupisten: — Hyvä Jumala, ota pois tämä tuska,
tee minut vaikka kerjäläiseksi, vaan anna sydämelleni lepoa! —
Rintaa ahdisti; piti likistää hampaat yhteen ja nyrkit kokoon, ettei
raju nyyhkytys herättäisi huonetoveria. Aamun valjetessa täytyi
hänen alottaa päivätyö raskaalla päällä ja kuumeen ruumiissa
polttaessa. Päivällä ei hän saanut tilojaan missään. Kun työ
viimeinkin oli päättynyt, riensi hän, vaatteet muutettuaan, Liinan luo.

— Sinä olet unohtanut Paavon, et puhu hänestä koskaan. Jos

minulla olisi mies ja lisäksi sellainen kuin Paavo, en ikinä suostuisi
elämään erilläni hänestä, — puhui Anni ärtyisellä äänellä Liinan
ommellessa koneella. Koneen kolina teki sanat kahta kovemmiksi ja
Liina tunsi kylmiä väreitä ruumiissansa.

— Kai hän on ensin unohtanut minut, koska hän jätti. Vai pitäisikö
minun juosta hänen jälessään?

— Muutamat näyttävät tykkänään unohtavan, mikä naineelle sopii,

— jatkoi Anni polttavin katsein.

— Mitä sinä oikein tarkoitat? — kysyi Liina, pysäyttäen koneensa.

— Kyllähän sinä sen itsekin tiedät! — huudahti Anni ilkkuen.

— Epäiletkö sinä jotakin Akun ja minun välillä tapahtuneen? Älä

pelkää. —

— Sinä olet aivan pikeentynyt häneen, näkeehän sen jo kaukaa. Ja

miehet ne ovat kyllä valmiit, missä vaan saaliin tapaavat. Olethan
sinä hieno ja hempeä, oikea miesten silmänruoka. Ethän sinä tahdo
viekotella ja kuitenkin muikistelet suutasi ja paistat särkiä! —

— Ja teen toiset mustasukkaisiksi! — huudahti Liina kiihtyneenä.

 — Mustasukkaiseksi! — huusi Anni hypäten ylös tuoliltaan. — Oho,
kaikille lampaille kanssa tässä kannattaisi olla mustasukkainen. Sinä
menit naimisiin kuin nauta tappolavalle, puoleksi peloissasi ja
uteliaana. Nyt tuulahtaakin vihreän niityn tuoksu nenääsi ja sinä
rimpuilet köydessäsi. Rimpuile sinä vaan! — Anni nauroi ja itki
raivoissaan raakojen sanojensa kiihdyttämänä. Intohimo oli murtanut
sen rajan, joka puolisivistynyttä suojaa raakuudelta.

Liinan polttava katse ja tavaton kalpeus todisti sanojen sattuneen.

— Koska minä olen lammas ja nauta, niin kuinka sinun sopii etsiä
minun seuraani? sanoi hän kuivasti.

Anni taisteli itkuaan vastaan. Tuolin selkään nojaten hänen

voimakas vartalonsa nytkähteli tuskan vallassa. Liinan suuttumus
haihtui tätä katsellessa ja hän läheni ystäväänsä lohduttaakseen
häntä. Samassa Anni hyppäsi ylös uhkaavana.

— Minä kirjoitan Paavolle, että hän kerrankin tulee kotiin

hoitamaan muijaansa. —

— Koska ei muija osaa hoitaa itseään, vai miten? Etkö jo kylliksi

ole haukkunut minua lampaaksi ja naudaksi. Kirjoita Paavolle,
kirjoita! Mutta sen sinulle sanon: et sinä sillä Akua saa, et, et! —
Liina oli suunniltaan. Annin uhkaus herätti hänessä rajun
katkeruuden.

— Kas, kuinka oletkin varma. Ehkä sinä oletkin jo Akun rak — —

— Mene ulos minun huoneestani! — huusi Liina vihasta liekehtivin

silmin.
 — Menen, en ikinä tahdo olla sinun likaisen pelisi todistajana.
Naimisiin osasit mennä, eikä sekään sinulle riittänyt, tarvitset vielä
sivumiehiä! —

— Vaiti! — huusi Liina särkyneellä äänellä, lyöden Annia vasten

suuta.

Anni, ollen voimakkaampi ja tanakka, tarttui toisella kädellään

Liinan ranteisiin ja toisella hän repäsi alas hänen raskaan nutturansa
ja löi tukasta kiinni pitäen kilpailijaansa kasvoihin.

— Paavo saa tietää, kyllä minä teidät! Tulkoonhan Aku — — —

Ovi lensi auki. Aku seisoi kuin kivettynyt Annin edessä otsasuonet
sinisinä.

— Sinä, sinä…! — änkytti Aku. Hän oli tukehtumaisillaan, jaksoi

tuskin pidättää kätensä koskettamasta naiseen.

— Kyllä, kyllä minä menen, — huohotti Anni kohottaen kätensä

suojakseen ja perääntyen ovelle, jonne Akun katse seurasi häntä,
kunnes ovi sulkeutui.

Liina itki rajusti painaen tulipunaiset kasvonsa vuoteensa

vaatteisiin. Suuri, vaalea tukka aaltoili kuin auringonpaiste hänen
hennon vartalonsa verhona.

Aku seisoi avuttomana keskellä lattiaa tajuamatta miten auttaisi

Liinaa. Kiihkeän halun valtaamana saada koskettaa tuota vaaleata
tukkaa, horjahti hän vastoin tahtoansa pari askelta itkevää kohti;
mutta Liina hypähti ylös huudahtaen:

— Älä koske minuun! —

 — En, enhän minä — — Pelkäätkö sinä? Katsos, menenhän minä
jo, — puhui Aku kuin lapselle.

— Pelkään, olenhan minä toisen vaimo! — Heidän katseensa

yhtyivät, mutta Aku näki vaan Annin herättämän tuskan ja häpeän
rakastettunsa kasvoilla, riuhtasi itsensä irti lumouksesta, syöksyi
ulos, juosten kadulle häpeissään kuin ruoskittu. Jos Aku olisi hetken
viivähtänyt, olisi Liina heittäytynyt hänen syliinsä. Nyt hän seisoi kuin
kivettynyt keskellä lattiaa, kuuli kuistinoven kolahduksen ja lapsen
itkua toisesta huoneesta. Ajatukset seurasivat Akua, joka astui katua
pitkin, hattu syvälle painettuna, hartiat luuhistuneina, ryhdittömänä.

— Vaikka koko maailma huutaisi, minä saan hänet kuitenkin, —

kuiskasi Liina voitonilosta värähtäen kesken masentavaa tuskaansa;
mutta samassa outo kauhu kuiskasi: — Näinköhän äitinikin tunsi? —
Häpeän puna nousi uudestaan poskille ja kädet tarttuivat kiireisesti
avonaiseen tukkaan. Hän palmikoitsi sen katsellen samalla Paavon
kuvaa seinällä. Syvä huokaus puristautui rinnasta. Se oli
voimattoman avunhuuto.

— Tämä oli edeltäpäin määrättyä, näin täytyi käydä — ajatteli hän.

— Minkä hän Paavolle voi? Ellei hän hyvällä anna eroa, ei pakkokaan
auta. Takaisin tuodaan vaikka poliisin voimalla. —

Väsyneenä oudosta mielenliikutuksesta, meni hän aikaiseen

levolle. Ensi kerran ajatteli hän leppeästi äitiään tuntien kumminkin
kammovaa ahdistusta verratessaan omaa mahdollista tulevaisuutta
äitinsä kohtaloihin. — Ei niin, ei niin, — jupisi hän silloin
ehdottomasti. — Ennen elän Paavonkin vaimona. Heikko olen
kuitenkin, heikko! —
 Etuhuoneessa joku kolisteli ja hetken kuluttua hapuiltiin hänen
oveaan.

— Kuka siellä? —

— Minä, Paavo, avaa! —

II.

Neljä vuotta oli kulunut. Liinaa ja Paavoa oli kova onni seurannut ja
pakottanut heidät muuttamaan kaupungin äärimmäiseen kolkkaan.

Marraskuun hämärässä illassa juoksivat rääsyiset poikavekareet

kapealla, kuoppaisella kadulla huutaen ja tapellen, jotta loka räiski
kahden puolen. Ohikulkevat toruivat, väsyneinä pujotellen
ränstyneitten kallistelevien rakennusten välillä, kuin haamut yön
hämärässä. Näitä kurjia katuja kulki Liinakin, kiireisesti astuen ja
kantaen maitokannua, leipää ja suolakalaa, jotka oli työstä
tullessaan ostanut. Hän suuntasi kulkunsa erästä piharakennusta
kohti, jonka portaita kattoi ränstynyt lautakoppi. Pimeään keittiöön,
joka oli kaikkien rakennuksessa asuvien yhteinen, kuului väsyneen
lapsen itkua ja miehen yskimistä.

— Erkki, kultaseni, älä itke, äiti tulee jo! Aino, missä sinä olet? —
Kukaan ei vastannut. Pikku Erkki huusi, eikä mies voinut yskältään
puhua. Liina juoksi naapurinsa suutarin kamarista tulta lainaamaan
ja sieltä hän löysi Ainonsakin. Arkulle asetettuna valaisi himmeä
lamppu köyhää huonetta. Poissa oli Liinan upea piironki peilinensä,
ompelukone ja muhkea sänky. Sijaan oli saatu kömpelö perhesänky
rääsyineen ja matkakirstu. Köyhyyden haju oli huoneessa pistävän
kitkerä.
 Pikku Erkki istui isänsä takana sängyssä itkien, jotta kyyneleet
valuivat pitkin kalpeita poskia ja laihat kädet kurkottivat äitiä kohti.
Silmät seurasivat äidin liikkeitä ja nyyhkytykset nytkäyttelivät pientä
ruumista. Lastansa avuttomampana makasi Paavo sängyssä, hänkin
katseillaan seuraten vaimoansa. Aino, äitinsä kuva, sinisilmäinen,
pyöreä tytöntyllerö, unohti kaiken nähdessään maidon, leivän ja
silakat arkunkannella. Molemmin käsin hän tarttui leipään, nakersi
sen syrjää kun hiiri terävillä hampaillaan, puraisi silakan selkään ja
ryyppäsi maitoa kannusta palan painimeksi.

— Voitko syödä, Paavo? sairas ravisti päätään.

Pikku Erkki sai hetken keikkua äidin käsivarrella askareita

tehdessä, juotettiin maidolla, pistettiin leivänpala käteen ja kiedottiin
uudestaan isän taakse sänkyyn.

— Nyt menen pesutupaan. Sieltä pilkoittivat valkeat; pyydän

hiukan lämmintä vettä vaatteilleni, — sanoi Liina, keräten mytyn
vaatteita kainaloonsa. Hän auttoi vielä Ainon sängyn jalkapäähän,
missä tytön tila oli, ja lähti pesutupaan.

Siellä akat liikkuivat kuin haamut sakeassa höyryssä. Lempeällä

hiljaisuudellaan oli Liina voittanut naapuriensa suosion, joten he
mielellään auttoivat häntä kun niin sopi.

— Tuohan tänne myttysi niin hierotaan yksin väin, — sanoi

Pärmäskä.

— Kyllähän minä ne itsekin — — taitaa tulla vaivaa — — olette

väsyneitä jo itsekin, — eitti Liina.
 — Ei ne kenenkään selkää katkaise. Itse taidat olla hyvinkin
väsynyt. Annas elättää neljä henkeä vaimo-ihmisen tällaisena aikana,
— sanoi suutarin vaimo.

— Eihän heissä suurta elättämistä ole. Paavo ei niin palaakaan ole

syönyt moneen päivään. Lapset vähän kuluttavat, — puhui Liina
jakaessaan vaatteet akoille.

— Voi, voi sentään, Liina, kun minä muistan sinut neljä vuotta
sitten, kuinka korea olit; ja miten nyt saat laahustaa yöt ja päivät. —

— Siitä on niin pitkä aika. Olen melkein unohtanut entiset

olemiset.
Enhän minä jouda ajattelemaan tyttöaikaista elämääni. —

— Voi mun päiviäni, vai pitkä aika, neljä vuotta; vastahan sinulla
on nenänpää, eikä ijänpää. Paljon on vielä edessäsi ja tällaistahan se
on köyhän ihmisen elämä: yhtämittaista raatamista, väliin yön ja
päivän kanssa. Toisinaan istu laiskana ja odota nälkäisellä vatsalla,
mistä taas rahanpennin leiväksesi irti saisit. Vielähän sinun kelpaa
kun on tehdas turvanasi ja vakinaista tuloa, — lohdutteli Pärmäskä.

— Eikä Paavokaan kauvaa elä, — sanoi suutarin vaimo.

— Jestas sentään, enhän minä häntä kuolemaan toivo! —

huudahti
Liina, vastenmielisyydestä hätkähtäen kuvaillessaan Paavoa
ruumiina.

— Ei suinkaan siinä parantumisenkaan toivoa ole. Se mies kanssa

on koettanut omasta ja muittenkin puolesta ja huonosti vaan kävi.
Putosiko se siellä Helsingissä, vai mistä se verta alkoi sylkeä? —
kysyi Pärmäskä.

— Putosi telineiltä. Ensin ei mitään tuntenut, eikä hoksannut

tapaturma-apua aikanaan vaatia, tuli kotiin sieltä ja oli hiljainen, ei
ollenkaan kuin ennen. Minun kävi kovin sääli ja kysyin usein, mikä
häntä vaivasi. Hän jaksoi kuitenkin kolme ensimäistä vuotta
maalailla; vasta tänä vuonna tuli turva sänkyyn. —

— Se on ollut riuska mies, sanonut suoraan herroille asiat ja

kyllähän sen ymmärtää mikä siitä seuraa. Milläs köyhä oikeutta
hankkii? — puhui Pärmäskä ojentaen pestyt vaatteet Liinalle.

Akat kahlasivat likomärkinä pihan poikki ja Liina kiipesi vinttiin

vaatteitaan kuivuulle hajoittamaan. Jokainen askel oli kuin
piiskanlyönti hänen heikolle selälleen. Alas tullessa pilkoitti valo
hänen huoneensa ovenraosta. Se oli suuri helpotus pimeässä
jännitetylle katseelle; mutta Liina huokasi: — palaa suotta lasten
maatessa! —

Ovea avatessa sattui hänen katseensa Paavon luiseen leukaan ja

nenään. — Kuinka teräväksi nenä olikin muuttunut ja harmaaksi,
silmät vaipuivat kuoppiinsa ja siristivät oudosti luomiensa alta. —

— Paavo, — huudahti Liina säikähtyneenä.

— Liina, — kuiskasi sairas hapuillen kädellään peitteen päällä.

Liina pani korvansa sairaan huulien eteen, pujotti kylmästä
kangistuneen kätensä sairaan luiseen kouraan ja kuunteli heikkoa
ääntä.
 — Jäät leskeksi; älä jätä lapsia — — lapsia. — Ääni hävisi korinaan
ja silmät avautuivat. — Lupaa, älä jätä! — sanoi hän nyt ääneensä.

Liina yritti irroittaa kättään, mutta sairaan sormet puristuivat lujasti

kuin rautakoura hänen ranteensa ympärille. Vielä sanoi kuoleva
selvästi: — Aino, Aino, palellut tyttöseni! — Sitten purskui verta
suusta ja sieramista tukehuttaen kauan kärsineen. Liina auttoi
kuolevaa mukavaan asentoon vasemmalla kädellään ja sulki hänen
silmänsä yritettyään irroittaa käsivarttaan. Mutta joka kerta kun hän
nykäisi rannettaan nytkähti kuolleen koko ruumis. Liinaa alkoi
kammottaa ja hätäisenä hän yritti irroittaa noita kangistuvia sormia
ranteestaan, lukien samalla rukouksia muististaan, tajuamatta omia
sanojaan.

— Äiti, minä joitin! — huusi Aino itkuisella äänellä ja herätti Erkin.

Molemmat lapset yltyivät ja Liina taisteli päästäkseen irti kuolleen
kammottavasta kättelystä.

— Lapset, odottakaa, — puhui hän hätäisesti ja taivutteli yksitellen

sormet irti ranteestaan. Vapaaksi päästyään juoksi hän suoraa päätä
naapurinsa suutarin ovelle huutaen:

— Tulkaa, Paavo on kuollut! — Sitten hän otti lapset pois sängystä

ja vei heidät suutarille. Hetken kuluttua oli suutarin vaimo kerännyt
koko huonekunnan ruumista korjaamaan. Hänen virttä veisatessaan
puettiin Paavo puhtaisiin ja nostettiin kovalle vuoteelleen laudoille.
Näitten puuhien ohessa alkoi Liinaa värisyttää. Hänen hampaansa
kalisivat, sillä pyykkituvassa kastuneet vaatteet kylmäsivät
syömätöntä ruumista ja kammottava jännitys oli tyhjentänyt loputkin
voimat. Uskovainen, hyvä suutarineukko lähetti hänet huoneeseensa
maata. Liina otti Paavon makuuvaatteet ja riensi levolle. Kamalalta
tuntui kääriytyä samoihin peitteisiin, joissa vielä oli jälkiä hyytyneestä
verestä, mutta väsymys kahlehti vastenmielisyyden ja jäsenet
hervahtivat lepoon.

— Mikä kolina se oli? Oliko hän pudonnut sängystään? Ei, hän

seisoi sängyn vieressä vääntäen rannettaan irti Paavon kourasta. Voi,
kuinka sitä pakottaa, pakottaa niin että päätä huimaa ja sydän
kirvelee ja nuo silmät… Paavo, mitä sinä tahdot? — Älä jätä lapsia!
— Paavo älä purista noin, päästä irti; minun ranteeni katkeaa, laske
irti, minä rukoilen, laske! — — — Missä hän on? Suutarilla
lämpöisessä. —

Uni hiipii uudestaan rauhaisena ja hyvänä virvoitellen väsynyttä.

Mutta päivä on armoton. Se ajaa uusiin huoliin ja vaivoihin, vaatien
vierimään virran mukana, pyörittämään kovanonnen ratasta, elämän
aaltoillessa rikkaana ja vapaana hänen ohitsensa.

Mitä hän nyt tekisi? Hänellä ei ollut varaa haudata miestään.

Lainaa ei saisi, sillä tavarat oli myöty ja syöty. Vaivaishoidolta saa,
sanottiin, pitää vaan ilmoittaa ja pyytää itse. Kyllä sieltä annetaan ja
miksi ei annettaisi? Olihan se heidän oma kassansa, johon kukin oli
maksanut monta vuotta. Omaansa sieltä kukin pyysi.

Liina oli kuin kone, joka väännettäessä panee rattaansa liikkeelle.

Odottihan Paavo laudallaan hautausta, vaivaishoidon hautausta.

Kaupungintalon raskas ovi narahti Liinan pelokkaana sitä avatessa.

— Rappusia ylös ja oikealle, — oli hänelle sanottu, — tuonne

varmaankin, mistä kuuluu ääniä. —

— Sinä olet sellainen maailman mätä-pilkku koko ihminen, ja ellet

tapojasi paranna viedään sinut pakkotyöhön, — huusi joku mies
julmasti kiroten jatkoksi. Liinan piti sukkelasti vetää kätensä pois
ovenrivasta ja juosta alas rappusia. — Ylöskö uudestaan? Ei tällä
kertaa, ennen kadulla kerjään; minä kerjään, ehkä joku hyvä
ihminen auttaa minua. — Taas ovi narahti Liinan astuessa kadulle
ihmisvilinään harhailemaan heikkona ja viluisena ohuissa vaatteissa.
Hän aikoi ojentaa kätensä vastaan tulevia, hienoja rouvia kohti ja
pyytää almua, vaan ääni ei totellut. Kylminä vaelsivat ihmiset hänen
ohitsensa, sivumennen ihaillen hänen kärsimysten kaunistamia
silmiään.

— Ruveta puhuttelemaan outoa naista kadulla! Kuka tietää, mikä

hulttio hän on, ja harvoin kukaan muuten kurjuuteen joutuu. —

Liina hoippui kotiinsa peläten ja paeten noita ihmisiä, joilta oli

aikonut apua pyytää, turvasi köyhiin ystäviinsä, itki ja rukoili heitä
vielä kerran auttamaan ja saattamaan Paavon hautaan. Eikä hänen
turhaan tarvinnut pyytää. Paavo haudattiin kunnialla ja Liina sai
lahjaksi mustan puvun itselleen ja lapsilleen.

Ruumis ja mieli juhlallisessa väsymyksessä istui hän

suruhuoneessa. Muistot heräsivät horroksista poistaen nykyisyyden
ja asettuen omistajansa tuomariksi. — Kyllä hän oli ollut sokea
ottaessaan Paavon. Niin, vaan äitini kohtalo. Olihan Paavo reipas
mies — — ahnas hauki ja onneton, niin onnettomia me olimme! Aku
tuli liian myöhään ja Paavo oli armoton, julma — jestas, sentään,
mitä mieleeni tulee! Eikö se ollut rikos kuollutta kohtaan? Kuka tiesi
vaikka olisi vielä kuulemassa ajatukset tässä vieressä.

Jäätävät väreet risteilivät ruumiissa, sydän pysähtyi, kunnes

paukahti uudestaan lujasti jyskyttämään ja kipeästi pakottamaan.
Onnettomuudet, ihmisteni kovuudet, omat erehdykset, kaikki ne
siinä ilkkuen nauroivat hänen heikkouttaan.
 *****

Liinan huone oli taas kalustettu. Akkunan edessä upeili pöytä

puhtaine liinoinensa, täynnä kaikenlaista sälyä. Siinä oli
punakantinen valokuva-alpumi, nelinurkkainen peili pienen lampun
varassa, koreita paperikukkia hohtavassa lasimaljassa, kampoja,
virsikirja, tuoksuva saippua, katekismus, lastenraamattu, postilla,
"Aarniometsän tyttäret", "Berliinin pyöveli", "Montekriston kreivi" ja
"Pariisin mysteeriot" rasvaisissa kansissa. Kuluneet kulmat osoittivat
kirjojen olleen ahkerassa käytännössä. Likaisten tapettien
rikkinäisyyttä peittivät kuvapaperit. Akkunan rumat, tummat puitteet
peittyivät valkoisten verhojen taa. Miellyttävä lämmin tuoksahti
tulijalle vastaan huoneeseen astuessa, sillä täällä asui pelkkiä naisia
puhtaine elämäntapoineen. Liina oli ottanut vuokralaisikseen kaksi
tehtaantyttöä saaden heiltä huoneensa vuokran. Muutenkin oli nyt
toimeentulo helpompaa kuin Paavon aikana. Liina ei vaan ottanut
reipastuakseen. Hänen suurissa sinisissä silmissään väikkyi samea
katse ja ryhti oli entistäkin koukkuisempi. Liikkeitten velttous ja
sieluton hymähdys todistivat elämään kyllästymistä ja
toivottomuutta.

Aino hiipi öisin lähelle äitiään vetäen peiton päänsä päälle.

— Kuinka sinä noin teet, — kysyi äiti

— Minä pelkään, — kuiskasi lapsi.

— Mitä tyhjää pelkäät, — rauhoitti äiti, painaen lasta lähemmäksi

itseään. Lapsen nukuttua tunsi hänkin pelon hiipivän yhä
lähemmäksi, toimeentulon ja nälän pelon.
 Ahtaat raha-ajat olivat pakottaneet tehtaita vähentämään
työväkeä. Joukottain siirtyi työttömiä ja leivättömiä toisille seuduille,
mutta joukottain jäi heitä kaupunkiin tarjoamaan työtänsä ala-
arvoisesta hinnasta vaikeuttaen siten toistensa toimeentuloa. Jälelle
jääneitä oli tehtaissakin vielä liian paljon, työtä ei riittänyt kylliksi;
moni sai odottaa tyhjin käsin päiväkaudet. Poistua ei saanut, siitä oli
sakko. Kuka voi sanoa millä hetkellä työtä tuotaisiin, menisi vielä
hukkaan sekin pieni ansio. Kyllähän siinä työttömänä nököttäissä
sattui mieleen kaikenlaista: katkeruus ja nöyryytys, uhka ja suru,
nuo työttömän työmiehen tutut mielialat. Vaan eihän siinä muukaan
auttanut, piti odottaa kärsivällisesti viikon loppuun saadakseen
vähintäin neljä, enintäin kymmenkunnan markkaa. Minnekäs meni
paremmilleen keskellä kylmää talvea.

Liina istui pieniruutuisen akkunan edessä pujotellen lankoja niisiin

ja kaiteisiin, kasvavan tytön kera. Työ oli pian loppuun suoritettu.
Kalvava pelko tämänkin niukan ansiolähteen kuivumisesta oli hänen
seuralaisensa odotustuntien hitaasti madellessa päivällisaikaan ja
iltaan. Häntä oli alkanut pistää rinnasta viime aikoina ja lyhyt, kuiva
yskä hävisi kuulumattomiin koneitten kohinaan, saaden yhä uutta
yllykettä tehtaan pölystä ja toivottomasta mielialasta. - Jos vielä
joutuisi sairashuoneeseen ja lapset — — —! — Hän hytkähti; joku
seisoi vieressä.

— Te olette kalpea kuin ruumis, — sanoi ystävällinen työnjohtaja.

Liina ei vastannut.

— Teillä on paha, kuiva yskä, menkää lääkärille! —

Hieno puna elostutti säikähtäneen poskia; hän oli odottanut

työnjohtajan sanovan: — Menkää pois, teitä ei ensi viikosta alkaen
tarvita! —
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com