Transaction Security

System
by D. G. Abraham
G. M. Dolan
G. P. Double
J. V. Stevens

Components of previous security systems were ple, a secret password; something that the person
designed Independently from one another and possesses, such as a brass key to a physical lock;
were often difficult to integrate. Described Is the
recently available IBM Transaction Security or something that biometrically identifies the per-
System. It Implements the Common son, such as a personal signature.
Cryptographic Architecture and offers a
comprehensive set of security products that Secret passwords and passphrases do not satis-
allow users to Implement end-to-end secure factorily prove that the person entering the infor-
systems with IBM components. The system
Includes a mainframe host-attached Network mation is the legitimate owner of the password
Security Processor, high-performance encryption rather than merely someone who successfully dis-
adapters for the IBM Personal COlDppter and covered the secret. Passwords and personal iden-
Personal SystemltJP Micro Channel"', an RS-232 tification numbers (PINs) can be guessed. In ad-
attached Security Interface Unit, and a credit-card
size state-of-the-art Personal SecurltytM card dition, the owners of passwords or PINs often
containing a high-performance microprocessor. write them down in convenient places in case
The application programming Interface provides they forget them, thus exposing them to unau-
common programming In the host and the thorized use.
workstation and supports all of the Systems
Application Archltecture™ languages except
REXX and RPG. Applications may be written to Similarly, using something the person owns, such
run on Multiple Virtual Storage (MVS) and PC as a key or token, as the sole means for granting
DOS operating systems. access does not prove the person presenting the
key or token is the legitimate owner rather than
merely the one who possesses it at that moment.
If the token also contains additional information,
such as a photograph of the owner, that may

C ompetition for development resources moti-

vates the design of long-lasting systems that
contain common elements. Developing a compre-
strengthen the proof, but such cards are routinely
forged.

hensive security system presents unique challenges Using a human characteristic that biometrically
in architecture, hardware, and programming. identifies a person provides the strongest and

Controlling access to the system capabilities is a:JCopyrlght 1991 by International Business Machines Corpo-
ration. Copying in printed form for private use is permitted
fundamental to a comprehensive design for a se- without payment of royalty provided that (I) each reproduc-
curity system. If it is relatively easy to alter the tion is done without alteration and (2) the Journal reference
parameters that control the system, security and IBM copyright notice are included on the first page. The
could be compromised. Such access is usually title and abstract, but no other portions, of this paper may be
copied or distributed royalty free without further permission
based on verifying the identity of a specific indi- by computer-based and other information-service systems.
vidual. Verification can be done through testing Permission to republish any other portion of this paper must
for something that the person knows, for exam- be obtained from the Editor.

206 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

most reliable means of user identification and au- unique to the Transaction Security System are
thentication. Systems that verify fingerprints implemented. 6
have been developed, but to many people there is
a stigma associated with the use of fingerprints for IBM's existing cryptographic products, 3848-
identification. Voice recognition has also been cusr" and the Programmed Cryptographic Facil-
used, although readily available high-fidelity re- ity (PCF) , 8 are used by a number of banks. How-
cording and playback equipment can accurately ever, this equipment does not adhere to all
replay voice information. Identification of the applicable standards of the American National
blood vessel patterns on the rear of the retina of
the eye has been proposed as well, but there
seems to be a reluctance to adopt such devices for
general application.

Attaching a written signature to a transaction as The Transaction Security System

a form of authorization is a common practice, and was specifically designed to
many times is a required part of transacting bus- meet all applicable ANSI and
iness in the financial community. The signing of a ISO standards.
name by an individual, if done in a "normal" man-
ner, is a dynamic action. The signature flows from
the pen to the paper without the individual think-
ing about it, and this action occurs in a remark-
ably repeatable fashion. The visible signature is
vulnerable to forging, but the dynamic variables Standards Institute (ANSI) and the International
such as pressure and acceleration associated with Organization for Standardization (ISO) because
producing the signature are much less so. such standards were nonexistent when the equip-
ment was developed. The Transaction Security
The IBM Transaction Security System, an- System was specifically designed to meet all ap-
nounced October 24, 1989, I was developed to plicable ANSI and ISO standards and to provide a
meet requirements of the financial industry. It im- common base for the future development of re-
plements the Common Cryptographic Architec- lated products and applications.
ture.? The system, shown in Figure 1, offers a
comprehensive set of security products that allow History
users to implement end-to-end secure systems
with IBM components. The Transaction Security Prior to the introduction of automated teller ma-
System includes an IBM 4753 Network Security chines (ATMs) the market for cryptography was
Processor for attachment to a host computer, essentially limited to the military environment or
high-performance encryption adapters for the IBM to host file and workstation communications.
Personal Computer and the Personal System/Z" Cryptography for the financial industry involves
(PS/2®) Micro Channel", an RS-232 attached IBM the use of the Data Encryption Algorithm (DEA). 9
4754 Security Interface Unit, a credit-card size The security obtained with the DEA is much like
state-of-the-art Personal Security?' card contain- that obtained with use of a combination lock. The
ing a high-performance microprocessor, and a details of the construction of the lock are not se-
signature verification pen and associated signal cret, but the combination used to open the lock is.
processor. The application programming inter- Similarly, the details of the DEA algorithm are
face ' (API) is common on the host and the work- public, and the security of the data is entirely
station, and it supports all of the Systems Appli- dependent on keeping a secret value, called the
cation Architecture" (SAA™) languages except key, secure from unauthorized individuals. 10
REXX and RPG. Applications may be written to run
on the Multiple Virtual Storage (MVS) and PC DOS The personal identification number (PIN) was in-
operating systems." The Transaction Security troduced into the financial industry as the ac-
System also implements several extensions to the cepted means of identifying a bank customer and
Common Cryptographic Architecture Crypto- approving a transaction when the customer was
graphic Programming Interface." In addition to not in the presence of a bank employee. Since
the cryptographic extensions, several services knowledge of the PIN coupled with the possession

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 207

 Figure 1 Transaction Security System products

SYSTEM/390 HOST
ANO SYSTEM/370 HOST
NETWORK SEOURITY
NETWORK SECURITY PROCESSOR
PROOESSOR MVS CONTROL PROGRAM
SUPPORT PROGRAM

ORYPTOGRAPHIC
ADAPTER

WORKSTATION
SECURITY SERVICES
PROGRAM

SECURITY
INTERFAOE
UNIT
SIGNATURE
VERIFIOATION
PEN
•
PERsoNAL
SECURITY
CARO
•
208 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991
of the ATM plastic card was sufficient proof for a the Personal Security card. System access is
bank to approve a transaction, protection for the granted when a signature is entered, using a spe-
PIN was required whenever it was entered or cially designed pen, that satisfactorily matches
transmitted. Cryptography provides the only the signature dynamics stored on the Personal Se-
practical means of protection for the PIN at all curity card.
points in the network where the PIN might be sub-
ject to hostile interception. Although cryptogra- IBM has worked on the problem of information
phy provided protection for the PINs, it presented asset protection for a long time. From the earliest
the bankers with the problem of how to manage the days it was clear that cryptography was the best
cryptographic keys. Bankers were not really inter- solution to the problem. In some early IBM equip-
ested in becoming cryptographic experts; thus an ment, the LUCIFER algorithm 11 was employed to
acceptable and competitive solution was needed. provide cryptographic protection. IBM's response
to a request from the United States government
The IBM financial products developed earlier have for a suitable general-purpose cryptographic al-
been used in many different environments and gorithm led to the development of the Data En-
were all designed at separate times according to cryption Standard (DES).12 Transparent session
then-emerging requirements. At their inception, level encryption (SLE) was included in the Ad-
PIN processing was still relatively new, and stan- vanced Communications Function/Virtual Tele-
dards had not yet been developed or even re- communications Access Method, or VTAM, along
quested. New ideas and constantly expanding with the introduction of the Programmed Cryp-
knowledge led to independent solutions to the tographic Facility. 8 VTAM SLE provides transpar-
same problem, not only among competitors but ent cryptographic protection to all information
also among IBM organizations. Interoperability flowing between a terminal and a host computer
was either difficult or totally impossible. In their or between hosts without the explicit involve-
zeal for market acceptance, product developers ment of the sending or receiving application. M-
implemented vastly different philosophies and ter the application "sends" a message, VTAM en-
techniques in large numbers. Such strategies led crypts the information before transmitting it to its
to expensive and long development cycles. These destination. When an application "receives" a
strategies can also create security weaknesses message, VTAM decrypts the information before
since different key-management systems need to passing it to the application. The IBM 3848 chan-
be accommodated. In many implementations, se- nel-attached cryptographic unit and the corre-
curity depended on the integrity of the designers sponding support program (3848-cusp) were in-
and programmers, thus enabling insiders to troduced a short time later to provide higher
launch attacks against equipment without detec- performance and a greater (hardware) level of se-
tion. Clearly, improvements were needed if IBM curity than PCF provided. These products also
were to continue to be a leader in the financial had an application-level interface that allowed us-
industry marketplace. er-written applications to encipher and decipher
data. Among early product offerings in the finan-
The Transaction Security System addresses these cial industry was the IBM 3600 Financial Trans-
specific problems and concerns voiced by cus- action System, which included primitive DEA
tomers. The system includes several novel phys- functions. The IBM 3624 ATM, the 4700 Financial
ical security features that are designed to fend off Branch System, and the 4730 Personal Banking
all but the most determined adversaries who are Machine provide additional cryptographic capa-
supported with unlimited resources. The system bilities to meet the requirements of more complex
has been designed to minimize any advantage that financial transaction processing.
the system designers might have by not relying on
the secrecy of designs or algorithms in any way. In 1985, it was decided that a unified security
Only the cryptographic keys and the PIN or pass- strategy and architecture would be an important
word that is used to gain system access need to be enhancement to the business strategy of the IBM
maintained as secrets, and an optional signature Consumer Systems Business Unit (CSBU). Defi-
verification feature removes the need for keeping nition of the security strategy included the devel-
the PIN or password secret. With this option, the opment of a pervasive security architecture that
dynamic variables involved in producing a signa- was to be followed by all CSBU product imple-
ture are stored on a "smart" card for users, called menters. As one of the efforts to reduce product

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 209

 development costs, product building blocks were sive joint studies with IBM customers in the bank-
defined to be reused in the development of future ing industry over a period of several years.
CSBU products. Additional objectives were formulated to be con-
sistent with IBM strategic directions and business
During the development of the security strategy, objectives. Participation in several ANSI an~ ISO
it was noticed that there was little or no common- financial security standards development projects
ality among the various predecessor products. ensured that the Transaction Security System
This finding led to a decision that a set of common would be consistent with emerging financial se-
functions should be defined to provide the same curity standards.
cryptographic functions at all points in the net-
work where cryptographic processing was re- A survey of customers produced a list of their
quired. This set of functions became known as the needs. Among them were an unobtrusive prod-
Common Cryptographic Function (CCF) set. uct, a common programming interface for pro-
grams written to run on the host and those wntten
A set of implementation-independent crypto- to run on the workstation, SAA if available, and an
graphic function definitions was proposed to pro- "acceptable" level of physical security. Most net-
vide interoperatability between products without works are operated 24 hours a day, so continuous
defining the implementation details to be fol- availability was important. Most customers do
lowed. These definitions were submitted to var- not have a full-time security staff and looked for
ious product development groups as a statement compliance with applicable national and interna-
of the cryptographic processing requirements of tional standards as a first-level measure of "good-
the CSBU products with a request that they be ness" of the equipment. Customers also needed
included in current and future machines to which turnkey solutions and the ability to control access
CSBU products might be attached. to the various system capabilities, as well as a
Several other non-CSBU products also had re- well-defined path for migration from current to
quirements for cryptographic processing. There- new equipment. Finally, they wanted assurances
fore, to obtain one design, responsibility was that whatever the product, it would be strategic,
transferred to a neutral group not having a spe- i.e., it would have IBM's commitment to use sig-
cific product interest, but which would have a nificant resources for its development as a prod-
strong interest and the capability to complete the uct with potential enhancement and growth.
development and definition of a comprehensive
and complete common cryptographic architec- The IBM business objectives were to satisfy the
ture. Thus the IBM Cryptographic Center of Com- customer requirements while developing a cost-
petence was chosen. The result of work by the effective product. These objectives usually mean
center was the Common Cryptographic Architec- minimizing the development expense. IBM man-
ture Cryptographic Application Programming In- agement was interested in developing a product
terface. The Common Cryptographic Architec- that was low in cost, could be developed quickly,
ture is to be used as the corporate strategic and had the maximum number of common com-
cryptographic architecture, and any IBM products ponents that could be used in future products.
employing cryptographic capabilities are re- Products that contained parts usable in other
quired to adhere to it. products were far easier to justify than were prod-
ucts that had all unique and unreusable compo-
With the center developing the Common Cryp- nents. Conformance to IBM and industry stan-
tographic Architecture, CSBU personnel were dards, as well as to the Common Cryptographic
able to spend their full time defining and devel- Architecture, was high on the list of desirable
oping the product set that would be used for se- qualities. Also, it was more desirable to develop
curing financial transactions throughout the net- strategic instead of tactical products.
work. Thus began the definition and development
of the Transaction Security System. The final objectives to be used to develop the
Transaction Security System were defined as a
Objectives common set of requirements taken from a series
of disclosures and studies with customers from
The objectives for development of the Transac- around the world. The Transaction Security Sys-
tion Security System were derived from exten- tem was to conform to SAA design requirements,

21 0 ABRAHAM ET AL. IBM SYSTEMS JOURNAL. VOL 30, NO 2, 1991

even if the product plans for the various required It was decided early that the Transaction Security
systems could not all be met during the develop- System would faithfully implement the Common
ment cycle. The security functions were to be Cryptographic Architecture. The question was
compartmentalized, that is, made separate and "when," because the Common Cryptographic
independent from one another, along with a gran- Architecture and the Transaction Security Sys-
ular and customer-selectable level of security. tem were on parallel development paths. Both
The Transaction Security System was to be in- were being tuned in response to new knowledge,
teroperable with existing and planned IBM secur- new customer demands, interoperability issues,
ity products, and a well-defined migration plan and sometimes just ordinary "bugs." In the final
was to be made available. Finally, the basic de- analysis, the Transaction Security System imple-
sign assumption was to be secure from insider ments the Common Cryptographic Architecture,
attacks. Although it is true that an insider seem- and it implements many compatible extensions.
ingly always has the advantage, there were to be Choices had to be made concerning what addi-
tional customer requirements were to be met.

The Personal Security card was being developed

while related industry standards were constantly
The Transaction Security System being updated and altered. Some of the standards
would implement the Common for smart cards (similar to credit cards but con-
Cryptographic Architecture. taining programmable circuitry) were not fully
compatible with the Common Cryptographic Ar-
chitecture. As a result, the product developers
attempted to anticipate the direction the stan-
dards would take and incorporate this informa-
no weaknesses in the design that might be ex- tion into a design for the Personal Security card
ploited by an insider having such knowledge. No that would meet requirements of both the stan-
"trap doors," undocumented "features," or dards and the Common Cryptographic Architec-
other secret ways to gain access to the system ture. In addition, IBM participated in the devel-
were to exist. opment of the smart-card standards.
Implementation challenges
There was an established market for security
All product development programs are challeng- cards, and other manufacturers were the acknowl-
ing. Many design choices and compromises must edged leaders in the marketplace. Whatever IBM did
be made. The Common Cryptographic Architec- needed to be compatible or at least interoperable
ture clearly defined the cryptographic services with the other cards while still maintaining product
that were to be implemented but did not cover differentiation to make the Transaction Security
such other aspects of the design as data entry, file System desirable and marketable.
formats, physical security, number of keys in key
storage, frequency or method of key change, and
equipment maintenance procedures. Several of Software for the system had to take into account
these parameters are usually determined by ex- the fact that program code was to reside in the
isting equipment and environments. same machine as other applications, with allow-
able code space in customers' machines ranging
Since IBM customers have major investments in from 5K to 600K. Most customers had PC DOS
the 4700 Financial Branch equipment and specif- with Operating System/Z' (OSIZ®) being their next
ically the 3624 ATM, it was necessary to protect logical step. Therefore, the logical plan was for
these investments as much as possible, yet also the product developers to implement the PC DOS
provide them with additional and improved func- version first. The OS/2 version would follow as
tion. In some cases, as new requirements were soon as resources permitted the work to be done.
studied and understood, it was necessary to be Likewise, the IBM PC 110 bus version of the Cryp-
careful to ensure that the Transaction Security tographic Adapter was given priority in develop-
System design provided support for existing ment to accommodate most customers' existing
equipment. hardware.

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 211

 Programming Programming interface. Since the computing
platforms of interest are generally the SAA plat-
As the product requirements emerged, it became forms, it was decided to adhere to SAA CPI (com-
clear that the hardware would have to be usable mon programming interface) practices. Work by
both in a control unit attached to System/370™ John Ehrman at the IBM Santa Teresa laboratory
had identified a set of practices that can result in
a "universally usable" programming interface.
The Ehrman guidelines were adopted so that a
single API could be defined for obtaining services
There is a procedure call consistently from any likely programming lan-
for each basic service. guage on any of the computing platforms. The
programming interface available with the Trans-
action Security System is a superset of the Com-
mon Cryptographic Architecture common
API. 2,3,5

and System/390™ processors based on personal Requests for service by applications or by the
computer technology and as individual products Transaction Security System utilities are commu-
connected to the IBM PC bus, Micro Channel, and nicated through a procedure call. There is a pro-
serial interface. The computing platforms would cedure call for each basic service, such as Enci-
include PC DOS and MVS with a strong desire to pher or Profile_Activate, with a fixed number of
support additional platforms including: parameters per service call. The call parameters
are simple address pointers to the variables that
• OS/2 are shared with the service. The variables are ei-
• System/88 ther four-byte, twos-complement integers, or
• Operating System/400® (OS/400®) strings. The parameters can point to single vari-
• Advanced Interactive Executive" (AIX®) for ables or to one-dimensional arrays. All commu-
PS/2 and the RISC System/6000™ nication between an application and a service is
via the call-identified variables-there are no side
Furthermore, the ability to offer cryptographic effects. Also, there is no concept of "open" and
services from one or more server machines on a "close"; a service is presumed to be always avail-
local area network (LAN) to other stations on the able.
LAN was felt to be desirable.
Applications can be written in a wide variety of
It was decided that the initial software offerings programming languages so long as the language
would support the hardware as a set of tools- supports the standard calling sequence for the
leaving the application development up to users computing platform. The applications are linked
and to providers of application software. Thus, with code supplied in an interface library. The
the software consists of an application program- linkage conventions are well standardized in the
ming interface with underlying function to control MVS environment. Conventions for the PC DOS
the hardware and with utilities to configure the environment are adapted from the dynamic link
hardware and provide other basic support. library (DLL) conventions of OS/2. PC DOS appli-
cation programmers must take these conventions
Application programming interface and support. into consideration when choosing a language
Applications have access to the capabilities of the compiler. The IBM "/2" compilers and assembler
hardware through a series of callable services at for PC DOS and OS/2 are specifically supported-
the programming interface. Calls to the interface other compilers may also be usable.
result in requests that are routed to a security
server for processing. The requests can have Request processing. The hardware can be in the
cryptographic functions performed, manage data same machine as the using application or in an-
on the Personal Security card, perform I/O oper- other machine on a LAN. In the case of the IBM
ations with the Security Interface V nit and Per- 4753 Network Security Processor, the machine
sonal Security card, and manage the hardware hardware is channel-attached to a System/370 or
access controls. System/390 processor. In other possible imple-

212 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

mentations the hardware could be in a coproces- Figure 2 Client-server request processing
sor configuration.

In order to accommodate the various connections

from applications to hardware, we selected a cli-
ent-server system concept. (See Figure 2.) Ap-
plications and utilities obtain service by issuing a APPLICATION PROGRAM OR PRODUCT UTILITY
procedure call. The procedure-call name is an ex-
ternal reference which is resolved by the linkage

-...---.,
PROCEDURE CALL
editor as an entry point in the product interface
code library. The interface code performs a pre-

-A~--r
liminary analysis of the request, then packages
the request in control blocks and data areas for
communication to the server code. Each platform
has a unique request communication scheme for
moving a request to the server. CLIENT INTERFACE CODE I+-- LINKED

PC DOS request process. In the single-station PC

DOS environment, the server is supplied address
l . r-- d

pointers to the control blocks and data areas, and

control is transferred from the interface code to
IMPLEMENTATION-DEPENDENT
REQUEST COMMUNICATION PROCESS II
the server through the use of an interrupt.

In the PC DOS LAN environment, the interface

1
SECURITY SERVER
1
code prepares request control blocks with point-
ers to the data and issues an interrupt. In con-
junction with the Financial Branch System Serv-
ices (FBSS) program, the control blocks and data SERVER
are concatenated into one or more transmission """,,,,--
blocks and sent over the LAN to the machine with
the server code.
HARDWARE DRIVER CODE
MVS request process. In the System/370 or Sys-
tem/390 environment, the interface code issues a TRANSACTION SECURITY SYSTEM HAFIDW,II,RE
program call instruction to transfer control to - CRYPTOGRAPHIC ADAPTER
protected code within the Network Security -SECURITY INTERFACE UNIT
-PERSONAL SECURITY CARD
Processor Support Program access method. In
the access method the individual requests are
transformed into control blocks and data and con-
catenated into a string. An exit is provided to the
MVS Security Access Facility where the Resource
Access Control Facility (RACF) can be used to
authorize performance of the service or use of a
key in key storage. Then multiple request strings the security server code. Cryptographic requests
can be combined into a single channel record for can involve secondary requests to a key-storage
transmission to the IBM 4753 Network Security server to obtain cryptographic keys. The security
Processor in order to reduce system overhead as- server prepares the detailed, bit-oriented control
sociated with channel I/O activity. The access blocks required by the hardware driver code and
method can route the blocked requests to one of initiates one or more I/O actions to perform the
several attached 4753s to distribute the process- request. The results are packaged into updated
ing load among multiple 4753s. control blocks and data areas, and the response is
communicated back to the interface code which
Server process. At the server, the control blocks places the results into the variables of the appli-
representing individual requests are examined by cation and returns control to the application.

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 213

 Types of service. The software supports the fol- • Manage the installation of master keys and ini-
lowing types of callable service requests: tial key-encrypting keys 14
• Customize the support software for different
• Cryptographic services-An application can re- memory environments
quest cryptographic services such as data ci- • Allocate Personal Security card data blocks,
phering, generation and verification of Message and read and write data in the blocks
Authentication Codes (MACs),13 and various • Provide support for the distribution of crypto-
key-management activities. graphic keys via paper, diskette, and Personal
Security card media
Individual cryptographic keys can be supplied
• Migrate cryptographic keys from older host
by the application, or the security server can products to the Network Security Processor
obtain the cryptographic key from a key-stor-
age server using a key label supplied by the
The batch initialization utility may be used with a
application. Certain types of keys can also be control file created in the previously mentioned
stored within the hardware in special key reg-
utility to quickly initialize the hardware with ac-
isters. The keys are packaged in a data structure cess control information and cryptographic keys.
known as a key token which contains the key,
the control vector, 14 and various processing
flags such as the type of data cipher processing.
Many different services are provided for man-
aging key generation, supporting key distribu-
tion, and storing long-life keys in a server-man- The hardware is supported
aged key storage. with several utilities.
The data ciphering operations support several
different methods for processing data that are
not eight bytes in length. Although the design
point is oriented to ciphering and authenticating
short data strings common in transaction proc- This utility also supports fast initialization of Per-
essing, very long strings can be processed in a sonal Security card groups that differ only in ID
single call or group of related calls. values, PINs, etc. A similar process is supported
in the Network Security Processor for setting up
• I/O service for the Personal Security card and that machine in a secure manner.
Security Interface Unit-Requests can be is-
sued to power-up a Personal Security card, al-
locate, read and write data blocks, eject the The building blocks
card, and read information from the Security Designing and developing a cryptographic system
Interface Unit keypad and access-protected requires special skills in addition to those skills
clock-calendar. normally required for any development project.
• Hardware access-control management-Each Cryptographic equipment by its very nature be-
of the hardware units contains an access-con- comes very important to an enterprise in that the
trol mechanism that determines which hard- equipment is used to protect the most valuable
ware commands can be performed. Services are resources of an enterprise. Since so much impor-
provided for activating the various profiles, tant data may be protected by such a system, the
causing the hardware to check passwords and user wants some assurance that the equipment
PINs or verify a signature against prestored sig- has been carefully and responsibly implemented.
nature reference information. By using common building blocks, we design
equipment that works together. In addition, the
Utilities. The hardware is supported with several development of functions represented by the
utilities that are part of the package. The utilities building blocks does not need to be repeated for
provide the tools needed to: the next product.

• Initialize the hardware with customer-specified The Transaction Security System is designed to
user and application command authorization operate with a very diverse set of systems and the
profiles technologies used in these systems, which in-

214 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

elude System/370, Systeml390, System/88, were certain security exposures inherent in the
AS/400™, IBM PC, and PS/2. Since each of these sys- multichip design. For example, a knowledgeable
tems has its own standard I/O bus architecture and adversary could attach probes to the wires be-
available voltages and packaging technologies, tween the chips and monitor the flow of informa-
defining a common hardware building block so tion. In this case the keys were in erasable pro-
"one size fits all" was extremely difficult. It was grammable read-only memory (EPROM) storage,
decided to define the Common Cryptographic and the DEA executed in the microprocessor com-
Function (CCF) set as the common building block. ponent. The secret cryptographic keys could be
It was a new idea to have a set of functions as a easily obtained in this way. The design goal was
building block. All previous building blocks had to develop a single chip that would fit the needs
been hardware components; this building block of both the Personal Security card and the reader
was the first that was a set of rules. The Engi- for the card.
neering Design System (EDS) had sets of rules as
building blocks, but these "rules" were sets of The HPS module. The high-performance Shield
logic gates that a designer put together to perform (HPS) module is the cryptographic facility for ex-
a function. The implementation of the underlying ecuting the Common Cryptographic Architecture
component was predetermined and fixed by EDS. services. All cryptographic operations take place
The implementation of CCF was left to individual inside the secured environment. Other services
design engineers. and extensions to the Common Cryptographic
Architecture are also executed in the HPS.
Implementers using the CCF building block were
free to select a technology most appropriate for Although a single-chip implementation would still
their environment and requirements. It was only be best, results of the cost vs function tradeoff
important that the definition of CCF be un- study to build such a chip were not favorable, and
changed. If the rules were followed, the new all required technologies were not available. Us-
product when completed would be cryptograph- ing the available technologies would result in a
ically interoperable with other equipment also im- very large chip. Such a large chip would not be
plementing CCF. Additional requirements led to suitable for use in the Personal Security card. It
the expansion of CCF into IBM's strategic Common was decided to take a less aggressive approach
Cryptographic Architecture. with respect to technology while adding signifi-
cant performance capabilities to the Shield mod-
The "ultimate" implementation would be a sin- ule concept.
gle-chip implementation of the architecture, in-
cluding the required support functions such as The HPS implements the entire Common Crypto-
memory, timers, I/O paths, etc. graphic Architecture function set. In addition to
the common functions, HPS contains several com-
The Shield module. The first implementation of patible cryptographic extensions not imple-
CCF was called the Shield module. Its compo-
nents were separate bare integrated-circuit chips
interconnected on a module substrate.
°
mented in other devices. Control vector 14 exten-
sion type allows a single key to be used for a
purpose such as generating a MAC, where use of
the key can be linked to individual employees and
Read-only memory (ROM) of the microprocessor multiple application divisions. The HPS module
component contained customized microcode in- will also contain the User Defined Function (UDF)
cluding a DEA facility 9 performing basic DEA func- facility. The UDF facility is used to implement
tions. Higher-level operations were implemented unique functions and proprietary algorithms to
using the DEA facility and other utility functions meet unique customer requirements. The func-
contained in the ROM. However, it was difficultto tions of Receive Session Key and Verify Cryp-
obtain the bare chips or the die for them from tographic Service Message provide a means of
manufacturers in a useful form prior to having implementing a key-distribution system where
them packaged. the receiving terminals can run unattended.

This same chip set was also used in the experi- HPS also implements a comprehensive set of non-
mental Personal Security cards. These cards were cryptographic functions for the purpose of sup-
used only under the control of IBM since there porting additional Transaction Security System

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 215

 functions such as signature verification, functions The second phase, also preceding the design, con-
for secure session establishment, and initial key sists of a study of known physical security pro-
loading procedures and functions. tection methods and the experience of others with
attacks against cryptographic systems, transac-
The lessons of the first Shield module taught us to tion systems, and computer systems in general.
not use individual chips for the second pass. It The study then shifts to the specific system to be
was decided to use surface mount technology and protected. Attack scenarios are proposed, and
off-the-shelf modules on a normal circuit card tests are conducted that will lead to an estimation
substrate. The second Shield module also was re- of the expected adversaries and possible attacks
against the system. Results from these prelimi-
nary studies are a great aid in knowing what to
protect against. These studies also help to identify
possible weak points during the early develop-
ment phase of the system. Early feedback to the
The Transaction Security System system designers allows design modifications to
utilizes many secret keys and be made that can enhance overall system secur-
ity.
authorization numbers.
The third phase uses the results of the preliminary
studies to conceive and propose tentative designs
of physical security and controls. The designs are
built as prototypes and characterized to deter-
quired to have much higher performance than the mine their potential effectiveness.
initial Shield module since it was intended to be
used in the workstation adapter as well as the host In the fourth phase, the physical security proto-
product. It therefore required a hardware DEA types are developed into reliable, manufactura-
processor. The physical security associated with ble, and cost-effective physical protection hard-
the HPS is discussed in the next section. ware which will be integrated into the Transaction
Security System.
Physical security for transaction systems The fifth phase involves evaluation of the final
The Transaction Security System utilizes many product. The effectiveness of the physical secur-
secret keys and authorization numbers. Effective ity design is evaluated through analysis, charac-
implementation of a secret-key cryptographic fa- terization, attack testing, and reliability testing to
cility, along with the high value of assets that the ensure that the original objectives have been met.
keys are protecting, requires significant physical
security to prevent the keys from being compro- Adversaries and attacks. The preliminary studies
mised. It was necessary, therefore, to define and laid the groundwork to define the classes of ad-
implement some special physical security fea- versaries expected and the types of attacks that
tures to protect the encryption keys for the ap- might occur against the Transaction Security Sys-
plication environments expected for the Trans- tem. Adversaries were grouped into three
action Security System, and to meet ANSI and ISO classes, in ascending order, depending on their
security standards. expected abilities and attack strengths.

Class I (clever outsiders)-They are often very

Design methodology. Implementation of effective intelligent but may have insufficient knowledge of
physical security requires that the design pass the system. They may have access to only mod-
through a number of phases. erately sophisticated equipment. They often try
to take advantage of an existing weakness in the
The first phase, which precedes the actual design, system, rather than try to create one.
consists of understanding the application envi-
ronment or how the system will be used, where it Class II (knowledgeable insiders)-They have
will be used, and by whom. This phase provides substantial specialized technical education and
details of what is to be protected in the system. experience. They have varying degrees of under-

216 ABRAHAM ET AL IBM SYSTEMS JOURNAL, VOL 3D, NO 2, 1991

Table 1 A security menu

Security
Level

ZERO

LOW Some security feature~ij ,'f~eyarerel<[Link]·ea,IlUYdefe~edwitb commOn. [Link]$hop t(>()ls

[Link],. soct~l'ijgJr IlJRal:lmicfoscope.
More expenslvetocls ar~r~~~;a$'Wellassomespe¢ializedknowledge..Tool cost may range tf<)$$soot3
$5000.
MOl) Special toolsandel:lui~.~ i~1![Link] welles sonte $[Link] knowledge:The· tools/Uld
equipmentmaYc9st {r',ll'J,J '$~!QOO. The attllck,ltlay become time-cQnsunililgbutwill eventuallY be
successful.
MOI)J:{ Equipmentisavai)abl~b\ltisex(:len~veto [Link]~~.Costmayrangefrom $50,000 to $200.000 or
more. Specialsltinsan4lmo"",I~l\I'erequiredto utilizetbeequipment for an attack. Morethan9ne
o,.,e~tion may [Link].s9tbatsevetal adversaries·[Link] would·haveto work: on·the
~t~k~quence. 'l'he attack could be unsuccessful.

Al1l<i10wn.!iftacks havebeenunsuccesmu. Some resel\Fch by a team Ofs~iI:llists is [Link]

spec~i2;edequipmentis .necesslU)',. some of which~t htl:v~to t~edesjgJl~llndbuilt;. 'I'otaleostoftbe
atta¢kCOllidbe one milliOn. dollllrsor more. The success Qftbe·attacldsllllcettain;

standing of parts of the system but potential ac- cial software) that is capable of subverting
cess to most of it. They often have access to software control and allows unauthorized ac-
highly sophisticated tools and instruments for cess into the system.
analysis. 3. Eavesdropping is the process in which sensi-
tive information is learned by picking up radi-
Class III (funded organizations)-They are able ated signals from various points in a system or
to assemble teams of specialists with related and a network of systems.
complementary skills backed by great funding re-
sources. They are capable of in-depth analysis of The attack study provided information that led to
the system. designing sophisticated attacks, and a proposed scheme of levels of security that are
using the most sophisticated analysis tools. They related to the strength of an attack required to
may use Class II adversaries as part of the attack overcome a given security implementation. By
team. relating the level of security to the difficulty of the
attack, the scheme, shown in Table 1. helped to
Attacks of the kind that could occur against the clarify the likelihood of an attack and to deter-
Transaction Security System were proposed, mine the physical security needed to minimize the
studied, and evaluated for level of difficulty over threat.
a period of two years with the use of the facilities
and services of a number of IBM locations. The Aspects of the design. A basic design objective of
attacks, some of which involved very sophisti- the Transaction Security System was that it
cated techniques and equipment, fell into three should be secure from Class II adversaries. Even
categories: with detailed design information, a single insider
should not be able to successfully compromise
1. Microcircuit attacks are aimed at the hardware the system. That level of physical security cor-
components where sensitive data are stored. A responds to the MODH level in Table 1. One might
successful attack bypasses all software con- justifiably ask why we should not protect against
trols and directly reveals encryption keys or all adversaries, including those of Class III. A
allows data to be altered. primary consideration was cost-effectiveness of
2. Counterfeiting and hardware simulation sub- the design. Protection at the MODH level may re-
stitutes hardware (and may include some spe- sult in only a small increase in the cost of the

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 217

 overall system, but protection at the HIGH level Reliability studies within IBM give confidence that
could conceivably double the cost of the system. the DES security module should function normally
The physically secure modules in which encryp- through the expected life of the system. Analysis
tion keys are held could generally be augmented of the design as well as some limited attack stud-
with a variety of additional security controls, de- ies within IBM on the security hardware incorpo-
pending on the level of assets to be protected and rated into the Transaction Security System pro-
the security environment in which the system re- vide the confidence that the MODH level of
sides. Any additional security features would physical security has been achieved. An indepen-
combine to provide the necessary overall security dent security evaluation by an external certified
for the system. security organization should provide additional
confidence to customers that the encryption keys
The physical security design concept imple- are sufficiently protected. It is important that the
mented in the secure modules of the Transaction external security organization be certified to en-
Security System consists of a primary security sure that it has the necessary knowledge and
layer backed up by a secondary defense which experience required for accurate physical secur-
protects against attacks that try to circumvent the ity design evaluations, and is trustworthy. After
primary security layer. The concept is shown in the security standard FIPS (Federal Information
Figure 3. Processing Standard) 140 is established, the Na-
tional Institute of Science and Technology (NIST)
has indicated an intention to certify approved
Encryption keys are stored in battery-backed organizations in the United States which would
semiconductor memory. The primary security provide certified evaluations of commercial cryp-
layer is made up of a flexible membrane, contain- tographic modules for physical security effective-
ing a fine screened conductive ink pattern that ness.
surrounds the key-storage devices and encryp-
tion circuitry. The membrane is coated with a
more durable material of similar chemistry. At- The cryptographic products
tempts to break through the material are very
likely to break the ink pattern. A detection circuit, The Transaction Security System consists of sev-
based on an original design from the IBM Thomas eral products which together can provide the se-
J. Watson Research Center, 15 detects the break in curity needed in transaction processing systems
the ink pattern and causes the keys to be thor- and networks. Each ofthe hardware products has
oughly erased, thus preventing disclosure of the a cryptographic engine that executes the Com-
keys and other secret data. The secondary de- mon Cryptographic Architecture and extensions.
fense consists, for example, of such features as a The hardware products are the only components
temperature detection circuit that will also cause where clear cryptographic keys are stored and
keys to be erased if an adversary attempts to used.
"freeze" the keys into memory and prevent the
erase circuit from working if the screen is Cryptographic Adapter. The IBM 4755 Crypto-
breached. graphic Adapter provides all of the cryptographic
functions in a high-performance package usable
Some standards, for example ANSI X9.17, recom- in either a workstation or the Network Security
mend overwriting the key-storage memory a Processor. It can be used for supporting applica-
number of times with unrelated data to minimize tions such as Systems Network Architecture
the chance of key recovery by an adversary. This (SNA) Session Level Encryption, transaction
may be prudent, but it is also expensive in terms "MACing," 13 and processing for the signature ver-
of the actual cost of additional circuitry and space ification feature.
on the circuit card. In addition, the overwrite cir-
cuitry may be subject to attack. It is suggested The Cryptographic Adapter is the highest-perfor-
that if the semiconductor key-storage memory de- mance member of the Transaction Security Sys-
vice cells are sufficiently characterized and un- tem components. It comes in one of two models.
derstood, and the erase mechanism is effective, One is an IBM PC I/O bus version for use in ma-
simple key erasure should be sufficient to protect chines such as the IBM PC, PC/XT™, and PC/AT®.
the keys from compromise at the MODH level. The other model is a Micro Channel version for

218 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

Figure 3 Conceptual block diagram of the intrusion protection method

CLEAR MESSAGE

,---------- - ---------------------------------------- - --------,

I I
I I
I POWER SWITCH POWER GATE CRYPTOGRAPHIC
PROCESSOR FUNCTIONS

S1 LOGIC NAND
~
I
~ GATE

I
I
I
I
I S2
¢- ~

VOLATILE
KEY STORAGE

S3
~

S4

L_____________________________________ _ ~

INTRUSION DETECTION SCREEN

METAL SHIELD GROUND

use in machines such as the IBM PS/2 Models 50Z, only memory (PROM) modules that are encapsu-
60, 70, and 80. lated inside the HPS.

The Cryptographic Adapter consists of a set of

building blocks which are assembled onto a raw The 64K bytes of random access memory (RAM)
adapter card. The primary building block is the inside the HPS is where the microcode maintains
HPS module that was described earlier. It is the all of the data needed by the adapter to perform
heart of the Cryptographic Adapter. All of the its function. Examples of the types of data stored
controlling microcode for the adapter and the in this RAM are a master key that is used for
microprocessor upon which the microcode is ex- encrypting or decrypting data keys and key-en-
ecuted are contained in the programmable read- crypting keys, user authorization tables, com-

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 219

 mand authorization tables, and global configura- terface Unit can be used as a functional substitute
tion data. for the Cryptographic Adapter when the cus-
tomer is interested in a lower-cost solution and is
Besides the HPS, there are several additional not concerned with lower performance.
blocks on the Cryptographic Adapter. It has an
additional 128K bytes of RAM that are currently The Security Interface Unit is a stand-alone box
with its own power supply. It has a tamper-resis-
tant enclosure, an integrated-circuit chip card
(i.e, smart card) reader, a 12-key keypad (similar
in appearance to a telephone keypad), a connec-
tor for the signature verification pen along with
The Security Interface Unit is a analog-to-digital circuitry for converting the an-
stand-alone box with its own alog signal from the pen, and a nine-pin RS-232C
power supply. communications port for attachment to a Cryp-
tographic Adapter or directly to the RS-232C
adapter of a workstation.

Inside the tamper-resistant enclosure is the logic

card for the Security Interface Unit. It contains
unused but are intended for future use by user- the microprocessor, 8K bytes of RAM which is
written programs. A battery maintains power to battery-backed, and 32K bytes of PROM which
the RAM inside the HPS whenever the power for contains the microcode. The DEA is implemented
the personal computer is off. Finally, there is a in software in the Security Interface Unit. The
serial communications chip and an RS-232 inter- tamper-resistant features are similar to those for
face for communicating to a Security Interface the HPS module previously described.
Unit and a socket for attachment of a signature
verification signal processor board. The Security Interface Unit provides a commu-
nications path to the Personal Security card via its
The Cryptographic Adapter microcode commu- integrated-circuit chip card reader. Through its
nicates with a device driver via several I/O ports keypad, it allows the secure entry of Crypto-
and direct memory access (DMA). A set of com- graphic Adapter and Personal Security card PINs.
mands and control blocks is defined. These com- It supports a subset of the Common Crypto-
mands and control blocks are transferred into the graphic Architecture services and stores in its
Cryptographic Adapter and contain the informa- RAM much the same type of information that the
tion necessary to perform the cryptographic and Cryptographic Adapter does.
other security-related functions.
Personal Security card. The Personal Security
The Cryptographic Adapter can perform a com- card provides a secure, portable cryptographic
prehensive set of the cryptographic functions de- processor that is capable of performing all of the
fined in the Common Cryptographic Architec- user authentication and authorization functions
ture. Some examples are: Encipher and Decipher defined in the Transaction Security System. In
in CBC 16 mode, Generate or Verify MAC, key- addition, it can be used to store any type of in-
management functions such as Re-encipher To or formation about or concerning the holder of the
From Master Key and Generate Key Set, and Personal Security card in its data blocks-user-
financial PIN functions such as Verify Encrypted definable data structures into which users can
IBM 3624 PIN and Generate Formatted and En- store any type of data that they wish. These data
crypted IBM 3624 PIN. blocks can be protected via a number of security
methods such as session key encryption. The
Security Interface Unit. The role of the IBM 4754 card is used to store the data containing the sig-
Security Interface Unit is to provide communi- nature dynamics for use by the signature verifi-
cations to and from the Personal Security card cation feature discussed next.
and support the secure entry of user authentica-
tion information via either the keypad or the sig- The Personal Security card is about the same
nature verification pen. Finally, the Security In- size, shape, and feel as a typical credit card, but

220 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

that is where the similarity ends. It incorporates The rest of the code is downloaded to the RAM on
a single integrated-circuit chip containing a proc- the daughter card.
essor and storage facilities, and it conforms to the
evolving ISO standards for the physical charac- Network Security Processor. The IBM 4753 Net-
teristics of integrated-circuit chip cards. work Security Processor provides DEA crypto-
graphic support for System/370 and System/390
The Personal Security card communicates with host processors. It can also perform financial PIN
the Security Interface Unit via block protocol ISO cryptographic functions. It connects to a Sys-
7816. Its single integrated-circuit chip contains a tem/370 or System/390 through a high-speed
CPU, 10K bytes of ROM that contains the base block-multiplexer channel. The application pro-
microcode, 256 bytes of RAM, and 8K bytes of gramming interface is used by the user-written
electrically erasable programmable read-only applications to implement secure transaction
memory (EEPROM). It implements the DEA in soft- processing system applications. Internal key stor-
ware. age of the 4753 can hold 70000 keys. There is an
internal cache that holds the first 10000 keys for
The Personal Security card stores basically the fast access. Keys not in cache are retrieved from
same type of data in its EEPROM as the 4754 and the fixed disk of the workstation, and a replace-
4755 do in their RAM; however, the card has the ment algorithm swaps the newer key for an older
capability of performing microcode patches via one in the cache. Multiple 4753s can be attached
its EEPROM. Neither of the other two devices has to a single host mainframe. The Network Systems
any patch capability. In addition, the Personal Program (NSP) MVS control program can control
Security card can use part of its EEPROM for data up to 16 4753s on a single host.
blocks. Data blocks give the Personal Security
card a portable file capability much like a diskette The Network Security Processor is based on an
has. IBM 7531 Industrial PC AT with the following items
added and changes made to convert it into a Net-
Signature verification feature. The signature ver- work Security Processor. A Cryptographic
ification feature consists of three pieces. First, Adapter is added, and a Security Interface Unit is
there is the signature verification pen which is attached to it. Two million bytes of additional
connected to the Security Interface Unit. It re- memory is added to be used as a cache for cryp-
cords signature dynamics by measuring the ac- tographic keys. A monochrome display is at-
celeration and rate of change of the pressure of tached, and a System/370 or System/390 channel
the pen tip. adapter card is added. A tamper-resistant enclo-
sure and service access door with lock are added.
The second piece of the signature verification fea- The ROM BIOS (Basic Input Output System) is re-
ture is the signature-processing daughter card moved and replaced with an altered version to
which plugs into the socket on the Cryptographic support operation without a keyboard (the Secur-
Adapter. On the daughter card are a signal proc- ity Interface Unit keypad is used for any key in-
essor and 128K bytes of RAM. The signal proc- put) and to prevent booting from the A-drive once
essor does numerically intensive computations installation is complete. Finally, the keyboard is
such as correlations, Fourier transforms, and removed. A Personal Security card is used for
floating point calculations which are part of the operator access, key transportation, and initial-
signature verification process. The RAM is used to ization.
contain additional signature verification micro-
code which is downloaded to the RAM by the Operation of the Network Security Processor is
Cryptographic Adapter device driver. controlled by the Network Security Processor
Control Program inside of it. In the System/370
The third piece is the signature verification mi- and System/390, the Network Security Processor
crocode. This microcode is in two parts. The main MVS Support Program provides application sup-
controlling code, including all code to communi- port for the Network Security Processor under
cate with the signature verification pen in real MVS/370, Multiple Virtual Storage/Extended
time and to read the signature reference data from Architecture (MVSIXA™), or Multiple Virtual
the Personal Security card, is located inside the Storage/Enterprise Systems Architecture
encapsulated module as part of the 256K PROM. (MVSIESA™).

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 221

 The access controls ification was successful, the Cryptographic
Adapter makes that user active and employs
The Transaction Security System has controls for the user's authority table for authorization of
accessing its various functions and capabilities. future commands until the user "logs off."
The controls are required to prevent unautho-
rized individuals from altering the system config- Obviously, this authentication method is not
uration and to discourage attackers from attempt- totally secure since the user's clear PIN is
available in the personal computer.
2. The Cryptographic Adapter and the Personal
Security card, in conjunction with the Security
User authentication is the ability Interface Unit, support secure entry of the us-
to determine that users are who er's PIN via the keypad on the Security Inter-
face Unit. In order for this method to work, a
they say they are. secure session must be in place between the
Security Interface Unit and the device 17 on
which the user's identity is being authenti-
cated. Secure sessions are discussed in more
detail later in this paper.
ing to use the capabilities of the system against
itself. The controls are used to authenticate the In the case where the user's identity is being
user, authorize what a user is permitted to do, and authenticated via the Personal Security card, a
exclude alien components from being introduced VERIFY PERSONAL SECURITY CARD PIN com-
into the system by requiring a secure session to be mand is sent to the Security Interface Unit. It
established before certain functions may be exe- enables its keypad and gathers keystrokes un-
cuted. til the Enter key is pressed. It then encrypts
the entered keystrokes under the session key
User authentication. User authentication is the shared between it and the Personal Security
ability to determine with high probability that us- card. The Security Interface Unit sends the
ers are who they say they are. An example in use encrypted value to the Personal Security card
today is the magnetic stripe card and PIN number where it is decrypted and compared against the
that an ATM user possesses. With these two stored PIN. The Personal Security card returns
pieces of "information," the ATM is able to au- an encrypted response to the Security Inter-
thenticate the user's identity. The importance of face Unit, which indicates success or failure.
this function is readily apparent with the realiza-
tion that it is undesirable for users to gain access In the case of authentication on the Crypto-
to a system by falsely stating that they are some- graphic Adapter, the process is slightly differ-
one else, since that other user may very well have ent and involves more application interaction.
different authorities and capabilities within the The application first sends a command to the
system. Security Interface Unit which asks it to do a
secure read of the keypad and return the re-
The Transaction Security System supports three sults encrypted under the session key, which
different types of user authentication, each of it shares with the Cryptographic Adapter. The
which has a different level of security. application then sends the encrypted result to
the Cryptographic Adapter for an ENCRYPTED
1. The Cryptographic Adapter supports a VERIFY VERIFY PIN command. The Cryptographic
PIN command that accepts the PIN in the clear Adapter decrypts the input and compares it to
(not encrypted) from the personal computer the stored PIN. It returns a response to the
application. The input PIN is compared inside application that indicates whether the user's
the secure area of the Cryptographic Adapter identity was verified. This authentication
against the stored PIN for that particular user. method offers more security than the first since
The Cryptographic Adapter returns a status the clear PIN is never outside any of the phys-
code that indicates whether the verification ically secure areas of the device. However,
was successful or not. In addition, if the ver- there is still the problem of the user exposing

222 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

 the PIN while entering it on the keypad of the the similarity score is above an acceptance
Security Interface Unit. threshold, the user's signature is verified. If the
similarity score is below a closeness threshold,
3. Signature verification is the most secure the user's signature is rejected. Upon acceptance,
method of user authentication. To perform sig- the new signature replaces the oldest signature on
nature verification, the signature verification the user's Personal Security card.
pen must be attached to the Security Interface
Unit, the signature verification processor card If the similarity score is between the closeness
must be installed on the Cryptographic threshold and the acceptance threshold, the new
Adapter, and the additional signature verifica- signature is compared against the three most re-
tion microcode must be downloaded to the
RAM on the signature verification card.
Because the signature verification process is
based on signature dynamics which are widely
believed to be unique to an individual, it is not Three types of tables control
sufficient to forge an individual's signature in
terms of appearance; instead the potential user authorization within the
forger must match the dynamics of the signa- hardware components.
ture. The user signs his or her name, and a
similarity score is calculated by comparing the
entered signature against reference signatures
from the user's Personal Security card. On the
basis of the similarity score, the user is ac- cent signatures. If the similarity of one of these
cepted or rejected. signatures to the new signature is above the ac-
ceptance threshold, the user's signature is accept-
Signature enrollment and verification. Signature ed; however, the system goes into an adaptation
verification is actually a two-step process. First, phase.
a user of the process must "enroll" his or her
signature into the system by signing his or her In the adaptation process, the system will regen-
name a minimum of five times. From among these erate the primary references just as it does during
five signatures, two are chosen as the primary the enrollment process. By means of the adapta-
references and the other three are temporarily tion process, the system keeps the signature ref-
designated the most recent signatures. This in- erences up to date, permitting gradual changes
formation is stored in data blocks on the user's that take place in a user's signature over time.
Personal Security card for future reference during User authorization. User authorization is a
the verification process. Communication of these method of determining whether a specific user has
data between the Cryptographic Adapter and the the authority to perform whatever function is be-
Personal Security card are protected by encryp- ing attempted. Obviously, such a determination is
tion under the session key. A description of se- highly important. For example, a bank teller would
cure sessions and session keys is given later. not normally have the authority to perform multi-
million-dollar electronic funds transfers, whereas a
The verification process, shown in Figure 4, high-level bank official could have the authority.
works in the following way. The reference signa- The Cryptographic Adapter, Security Interface
tures are read by the Cryptographic Adapter from Unit, and Personal Security card are highly config-
the user's Personal Security card. This informa- urable with regard to user authorization.
tion is protected by encryption under the session
key shared by the Cryptographic Adpater and the Three types of tables control user authorization
Personal Security card. The user is prompted to within the hardware components. One defines the
sign his or her name with the signature verifica- authority necessary to perform each hardware
tion pen. The analog data from the pen are digi- command. The second defines the authority that
tized and encrypted by the Security Interface an individual user has. The last defines a table of
Unit and sent to the Cryptographic Adapter. 16 holidays when the execution of most com-
These data are then compared against the primary mands is not allowed. All of the tables are con-
references and a similarity score is generated. If figurable by the user if authorized.

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 223

 Figure 4 The signature verification process

224 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

Each of the three devices has a Command Con- The Cryptographic Adapter contains a public
figuration Table (CCT). The CCT has a two-byte UDB, a guest UDB, and four individual UDBs. The
entry for each command that the hardware device Security Interface Unit contains a public UDB and
supports. The first byte of each entry contains a a guest UDB, and the Personal Security card con-
series of flags that define certain attributes about tains four individual UDBs.
the command as follows:
A User Data Block contains a number of fields
that define the authority privileges of the user.
• Command unavailable. This option permits the The fields are:
command to be completely disabled under all
circumstances. • User II~An eight-byte field that identifies the
• ESS required. This option permits the command
user
to be processed only if a secure session is in • PIN-An eight-byte field that contains the value
effect between the sender of the command and the user must enter in order to authenticate his
the device that executes the command. or her identity when not using signature verifi-
• Enable date and time checking. This option per- cation
mits the command to be disallowed when the • Verification method-A two-bit field that indi-
user is attempting to execute the command and cates which methods of user authentication are
the date or time is outside of the user's limit. valid for this user. The possible values are: PIN
• Initial verification required. This option permits only; signature only; PIN or signature, signature
requiring that the user's identity be authenti- required if it is present.
cated (via one of the methods discussed previ- • Verification failure count-A one-byte field
ously) before the command can be executed. that records the number of times the user has
• Pre-execution authentication required. This failed PIN authentication. It is reset to zero
option permits requiring the user to make an when the user's identity is successfully verified
authentication each time before executing the via a PIN.
command. • Verification failure limit-A one-byte field that
• Exact authorization level required. This option contains the maximum number of invalid PIN
permits requiring the user's authority level to authentication attempts the user is permitted
exactly match that of the command. before being locked out
• User authority level-A one-byte field that con-
The second byte of each CCT entry contains the tains the authority level of the user. It is com-
required authority level of the command. De- pared against the required authority level of a
pending on the value of the exact authorization- command whenever the user attempts to exe-
level-required flag, the user's authority level must cute a command.
either exactly match or be greater than or equal to • Command authorization fiags-A series of
that of the command in order for the user to be flags. There is one flagfor each command. Ifthe
permitted to execute the command. flag is on, the user is permitted to execute the
command (given that the user passes all other
Each of the devices has some number of User authority checks). If the flag is off, the user is
Data Blocks (UDBs). The number of UDBs varies not permitted to execute the command.
from device to device. There are three different • Expiration date-A date defining the last date
types of UDBs as follows, although all of them on which the user will be permitted to use the
contain the same type of data: device
• Valid days ofweek-A series of flags that define
which days of the week the user is permitted to
• Regular UDBs that correspond to individuals use the device
• Public UDBs that are active when no other type • Time limits-Made up of two fields: a lower
of UDB is active time limit and an upper time limit. The user can
• Guest UDBs that are downloaded from the Per- only use the device when the current time is
sonal Security card to both the Cryptographic within these limits.
Adapter and the Security Interface Unit after a
Personal Security card user has been authenti- Secure sessions. Secure sessions are a concept
cated wherein two entities temporarily connect and es-

IBM SYSTEMS JOURNAL, VOL 30. NO 2. 1991 ABRAHAM ET AL 225

 tablish a session key that the two entities share The devices use the session key to protect infor-
and no other entity knows. The Cryptographic mation that they transmit across the interlaces
Adapter, Security Interlace Unit, and Personal between one another. The information can be
Security card support secure sessions among protected by either encryption or "MACing." For
example, the Cryptographic Adapter does not
contain a clock, so to obtain the current date and
time (in order to do date and time checking), it
sends a READ CLOCK command to the Security
Interlace Unit. The Security Interlace Unit ap-
The session key protects pends a MAC to the date and time which it returns,
information which devices and the Cryptographic Adapter then does a MAC
transmit across the interfaces Verify on the date and time before accepting it.
between one another. Secure sessionprocess. We now describe the proc-
ess that the devices use to establish a secure ses-
sion. The process consists of two main parts: (1)
establishing a session key and (2) verifying that
the two devices have established identical session
themselves and also between themselves and keys.
some outside entity. Each device supports a dif-
ferent number of secure sessions. In addition, In the following discussion, the secure session
some number of the secure sessions are reserved establishment process will be examined from the
for use among the devices themselves. point of view of two devices establishing the se-
cure session between themselves. The process is
The Cryptographic Adapter supports three se- slightly modified if a third party is orchestrating
cure sessions. The Security Interlace Unit sup- the establishment of the secure session between
ports up to eight secure sessions, and the Per- two devices.
sonal Security card supports two. The first two
secure sessions supported by the Cryptographic As a prerequisite for the establishment of the se-
Adapter and the Security Interlace Unit are re- cure session, a shared key-encrypting key (KEK)
served, whereas just the first secure session of the must be loaded into the appropriate entry in the
Personal Security card is reserved. KEK table of each device.
The secure session establishment process results In establishing the session key, in all cases of
in a randomly derived secret session key that the secure-session establishment, one device has to
two entities share. In the case of the secure ses- be in control ofthe process and driving it. For the
sion established among the devices, the session secure session between either the Cryptographic
key has the following properties: Adapter and the Security Interlace Unit or the
Cryptographic Adapter and the Personal Security
• It is a data-compatibility key with Encipher, card, the Cryptographic Adapter is the control-
Decipher, MAc-Generate, and MAc-Verify priv- ling device. For the secure session between the
ileges. Security Interlace Unit and the Personal Security
• Only internal functions of the device can access card, the Security Interlace Unit is the controlling
it. It cannot be accessed as a normal key. device.
• It changes each time a new secure session is
established. The Cryptographic Adapter and First, the controlling device generates a random
the Security Interlace Unit each attempt to es- eight-byte key using its random number genera-
tablish a secure session with a Personal Secur- tor. This random key is the session key. The con-
ity card whenever it is inserted into the Security trolling device stores the session key in the ap-
Interlace Unit, and the Cryptographic Adapter propriate entry in its session key table. The entry
and the Security Interlace Unit attempt to es- used depends on the device with which the con-
tablish a secure session whenever they are pow- trolling device is attempting to establish the se-
ered on. cure session.

226 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

Next, the controlling device will triple encrypt the effectively a GENERATE CHALLENGE QUAN-
session key under the appropriate KEK stored in TITY command.
its KEK table. It will use a control vector that 2. Device A sends the clear random number to
specifies data compatibility with Encipher, Deci- device B as part of a GENERATE CHALLENGE
pher, MAc-Generate, and MAC-Verify privileges. RESPONSE command. B encrypts the random
number with the session key that it shares with
Finally, it will load the session key into the device A and returns the result to A.
with which it is attempting to establish the secure 3. Device A decrypts the value received from B
session via the LOAD SESSION KEY command. The with the session key, which it supposedly
parameters for this command are the encrypted shares, and compares the result with the orig-
session key, the control vector, the entry number inal random number that it had saved in
in the KEK table of the target device to use for Step 1.
decrypting, and the entry number in the session
key table of the target device in which to store the If the comparison in Step 3 was a match, device
clear session key. The target device will decrypt A knows that device B shares the same session
the session key using the supposedly shared KEK key as it does, and the secure session establish-
and store it into its session key table. ment process is complete.

After the session key is loaded, both devices need

to verify that in fact, they do share the same ses- Summary
sion key. This verification is done by using a
The IBM Transaction Security System has been
three-step process performed first in one direc-
tion and then in the other. described and some of the challanges associated
with its development have been discussed. The
development of a security system presents unique
Assume that the two devices are called A and B,
challanges for which there exists no exact para-
and further assume that A is the controlling de- digm. Common sense along with good solid en-
vice. The steps in the process work as follows:
gineeringjudgment provide the best guidance for
such an undertaking.
1. Device A sends a GENERATE CHALLENGE
-QUANTITY command to device B. Device B
Such a system will continue to evolve with addi-
returns an eight-byte random number in the
tional enhancements and improvements in re-
clear (i.e., not encrypted). B also saves this
sponse to customer demand. The same principles
random number for later use.
will guide the development of those enhance-
2. Device A encrypts the random number using
ments as were used for the original work.
the session key that it supposedly shares with
B. This step is effectively a GENERATE CHAL-
LENGE RESPONSE command. Acknowledgments
3. Device A sends the encrypted random number
back to B as part of a VERIFY CHALLENGE RE- The authors of this paper wish to acknowledge
SPONSE command. B decrypts the value and the following people who made significant con-
compares it to the original random number it tributions to the development of the Transaction
generated in Step 1. It then returns a response Security System: S. G. Aden, T. W. Arnold,
to A that indicates whether the comparison G. Bourbeau, T. J. Chainer, S. Deskevich,
matched. M. B. Forbes, G. B. Fryer, D. Hrelic, D. B. Jacobs,
D. B. Johnson, M. R. Kelly, J. W. Lamb, A. V.
If the comparison in Step 3 matched, device B Le, S. M. Matyas, E. H. Nachtigall, S. W. Neck-
knows that device A shares the same session key yfarow, R. Prymak, W. S. Rohland, S. L. Schi-
as it does; however, A cannot be positive that the fano, P. D. Smith, D. J. Sundberg, A. B. Wadia,
session key ofB is identical to its own. Therefore, S. H. Weingart, and S. E. Wince.
the process is repeated in the following manner:
Personal System/2, Micro Channel, PS/2, OS/2, Operating
System/400, OS/400, AIX, and PC AT are registered trade-
1. Device A generates an eight-byte random marks, andPersonal Security, Systems Application Architec-
number and saves it for later use. This step is ture, SAA, Operating System/2, System/370, Systeml390, Ad-

IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991 ABRAHAM ET AL. 227

 vanced Interactive Executive, RISC System/6000, AS/400, IBM Data Security Through Cryptography, GC22-9062, IBM
PC/XT, MVS/XA, and MVS/ESA are trademarks, of Inter- Corporation; available through IBM branch offices.
national Business Machines Corporation. IBM Transaction Security System: General Information and
Planning Guide, GA34-2137, IBM Corporation; available
Cited references and notes through IBM branch offices.
IBM Transaction Security System: Programming Guide and
I. See the appropriate announcement letters: No. 189-174 Reference, GC31-2934, IBM Corporation; available through
(IBM 4754 Interface Unit, 4755 Cryptographic Adapter, IBM branch offices.
Personal Security Card and Signature Verification Pen), IBM Work Station Security Services Installation and Oper-
No. 189-171 (IBM 4753 Network Security Facility), ating Guide, SA34-2141, IBM Corporation; available through
No. 289-585 (NSP MVS Host Support Program Product IBM branch offices.
No. 5706-028).
2. Common Cryptogtaphic Architecture, Cryptographic IBM Work Station Security Services Licensed Program Spec-
Programming Interface, SC40-1675, IBM Corporation; ification, GC31-2720, IBM Corporation; available through
available through IBM branch offices. IBM branch offices.
3. D. B. Johnson et al., "Common Cryptographic Architec- IBM 4753 Network Security Processor Installation and Op-
ture Cryptographic Application Programming Interface," erating Guide, SA34-2139, IBM Corporation; available
IBM Systems Journal 30, No. 2, 13~150 (1991, this is- through IBM branch offices.
sue). IBM 4753Network Security Processor MVS Support Program
4. IBM has issued a statement of direction for support of Installation and Operating Guide, SA34-2139, IBM Corpora-
System/88 and Operating System/2. tion; available through IBM branch offices.
5. D. B. Johnson and G. M. Dolan, "Transaction Security IBM 4753Network Security Processor MVS Support Program
System Extensions to the Common Cryptographic Archi- Licensed Program Specification, GC31-2933, IBM Corpora-
tecture," IBM Systems Journal 30, No. 2, 23~243 (1991, tion; available through IBM branch offices.
this issue). USA Federal Information Processing Standard, Data Encryp-
6. Transaction Security System Programming Guide and tion Standard, 46-1-1988, National Bureau of Standards (now
Reference, SC31-2934, IBM Corporation; available NIST), U.S. Department of Commerce, Washington.
through IBM branch offices.
7. 3848-CUSP stands for the IBM 3848 Cryptographic Unit
and Cryptographic Unit Support-OSIVS2 MVS Program Dennis G. Abraham IBM Services Sector Division, 1001
Product No. 5740-XY6. W. T. Harris Boulevard, Charlotte, North Carolina 28257.
8. The IBM Programmed Cryptographic Facility Program Mr. Abraham is a Senior Technical Staff Member in the Se-
Product No. 5740-XY5. curity System Architecture area, where he has been a leader
9. For information about the Data Encryption Algorithm, in establishing the architecture and function definitions for the
see ANSI X3.92 or FIPS-46. Transaction Security System. He graduated from Fairleigh
10. For additional information on the DEA, see S. M. Matyas, Dickinson University with a B.S.E.E. degree in 1964,and he
"Key Handling with Control Vectors," IBM Systems received his M.S.E.E. from Syracuse University in [Link]
Journal 30, No.2, 151-174 (1991, this issue). joined IBM in June 1964 at Endicott. New York, where he
11. S. M. Matyas and C. H. Meyer, Cryptography: A New held assignments in various product and service groups,
Dimension in Computer Security, John Wiley & Sons, among which were circuit design and logic design with a
Inc., New York (1982), p. 115. strong speciality in servomechanisms, including a special ex-
12. W. F. Ehrsam, S. M. Matyas, C. H. Meyer, and W. L. pertise in stepper motor control and design. He was the lead
Tuchman, "A Cryptographic Key Management Scheme architect of the IBM 3890OCR machine and, after moving to
for Implementing the Data Encryption Standard," IBM Charlotte in [Link] worked in developing image technology
Systems Journal 17, No.2, 106-125 (1978). as it applies to check processing. After an assignment in the
13. For more information about the Message Authentication former National Marketing Division headquarters where he
Code, see ANSI X9.9 or ISO DP 8730. provided technical expertise for the marketing force, Mr.
14. Op. cit., Reference 10. Abraham joined the advanced technology group and was as-
15. S. Weingart, "Physical Security for the ILABYSS Sys- signed to develop a security strategy and architecture for the
tem," Proceedings of the 1987 Symposium on Security Consumer Systems Business Unit. This work led to the de-
and Privacy (1987), pp. 52-58. velopment of the Transaction Security System and the Com-
16. CBC is the Cipher Block Chaining mode of the DEA; see mon Cryptographic Architecture. He holds nine issued pat-
ANSI X3.106. ents, ten patents on file, and 23 published invention
17. In the discussion that follows in the text, the term "de- disclosures.
vice" is understood to signify one of the components of
the Transaction Security System.
George M. Dolan IBM Services Sector Division. 1001 W. T.
Harris Boulevard. Charlotte, North Carolina 28257. Mr. Do-
General references lan graduated from Lehigh University with a B.S. in electrical
engineering. Since joining IBM at Endicott, New York, in
D. G. Abraham, G. P. Double, and S. W. Neckyfarow, Secure 1961, he has had design responsibilities for various commu-
Component Authentization System, U.S. Patent No. nications hardware and software products, which in recent
4,799,061 (January 17, 1989). years have been principally for the worldwide finance indus-
IBM Cryptographic Subsystem Concepts and Facilities, try. Mr. Dolan is a senior engineer in the IBM Secure Work-
GC22-9063, IBM Corporation; available through IBM branch station Development department. His work on the Transac-
offices. tion Security System has involved integrating cryptographic

228 ABRAHAM ET AL. IBM SYSTEMS JOURNAL, VOL 30, NO 2, 1991

processors into IBM PS/2 and MVS systems, and integrating
the result into customer applications for the protection of data
and user identification. His responsibilities include specifying
the user programming interface and software structure in sup-
port of the Transaction Security System.

Glen P. Double IBM Services Sector Division, 1001 W. T.

Harris Boulevard, Charlotte, North Carolina [Link]. Dou-
ble is an advisory engineer/physicist and is currently respon-
sible for physical security on the Transaction Security Sys-
tem. He received a B.S. degree with honors in engineering
physics from the University of Toledo. He attended Wayne
State University under a National Science Foundation train-
eeship and received an M.S. in solid state physics. Before his
present assignment in Charlotte, he worked in various areas
at the IBM facilities in East Fishkill, New York, and the for-
mer Instrument Systems Division. He has a broad background
in integrated circuits and electronic packaging technologies,
magnetics, electro-optics, lasers, and radiation effects in sol-
ids.

JamesV. Stevens IBM Services Sector Division, 1001 W. T.

Harris Boulevard, Charlotte, North Carolina 28257. Mr.
Stevens is a staff programmer in Secure Workstation Devel-
opment. He joined IBM in Charlotte in 1983after receiving a
B.S. in computer science from the University of Missouri at
Rolla. He is nearing completion of an M.S. in computer sci-
ence from the University of North Carolina at Charlotte. For
the past three years, he has been involved with the design and
development of the device drivers and microcode for the IBM
4755 Cryptographic Adapter. His current assignment is the
coordination of the OS/2 software development effort for the
Transaction Security System.

Reprint Order No. 0321-5431.

IBM SYSTEMS JOURNAL, VOL 30, NO 2. 1991 ABRAHAM ET AL. 229