Sic

Security In Computing
Unit 1
1.0 INTRODUCTION TO SECURITY
Security refers to any measures taken to protect something. Examples of

security in the real world include locks on doors, alarms in our cars, police officers.
Computer security is a field of computer science concerned with the control of risks
related to computer use. It describes the methods of protecting the integrity of data
stored on a computer.In computer security the measures taken are focused on securing
individual computer hosts.
Network security consists of the provisions made in an underlying computer network

infrastructure, policies adopted by the network administrator to protect the network
and the network-accessible resources from unauthorized access and the effectiveness
(or lack) of these measures combined together. It starts from authenticating any user.
Once authenticated, firewall enforces access policies such as what services are
allowed to be accessed by the network users. Even though it prevents unauthorized
access, it prevents harmful contents such as computer worms being transmitted over
the network. An intrusion prevention system (IPS) helps detect and prevent such
malware.
1.1 Threats in Network Security
The following describe the general threats to the security of the distributed systems
Disclosure of information
Organizations maintain valuable information on their computer systems. This

information may be used by other parties in such a way as to damage the interest of
the organization owning the information. Therefore information stored on or
processed by computer systems must be protected against disclosure both internal and
external to the user organization.
1
Contamination of information
Valuable information may become worthless if unauthorized information is mixed

with it. The damage may be as great as the damage through information disclosure.
Unauthorized use of resources
Unauthorized use of resources may lead to destruction, modification, loss of integrity

etc. of resources and thus the authorization of individual users will be limited.
Misuse of resources
Authorized use of resources may give authorized individuals the opportunity to

perform activities that are harmful to the organization. Misuse of resources,
intentional or accidental, may be harmful to the organization through corruption,
destruction, disclosure, loss or removal of resources. Such misuse may affect the
liability of an organization for information entrusted to it or for transactions and
information exchanged with other organizations.
Unauthorized information flow
In a distributed system, information flow must be controlled not only between users of
end-systems but also between end-systems. Depending on the prevailing security
policy information flow restrictions may be applied to the basis of classification of
data objects and end-systems, user clearances, etc.
Repudiation of information flow
Repudiation of information flow involves denial of transmission or receipt of

messages. Since such messages may carry purchasing agreement, instructions for
payment etc., the scope for criminal repudiation of such messages is considerable.
Denial of service
Because of the wide range of services performed with the aid of computer systems,
denial of service may significantly affect the capability of a user organization to
2
perform its functions and to fulfill its obligations. Detection and prevention of denial
of service must be considered as part of any security policy.
1.2 SECURITY SERVICES
In order to protect against perceived threats, various security services need to be

provided, the main security services are:
Authentication
Authentication is the process of proving the identity of a user of a system by
means of a set of credentials. Credentials are the required proof needed by the system
to validate the identity of the user. The user can be the actual customer, a process, or
even another system. A person is a validated through a credential. The identity is who
the person is. If a person has been validated through a credential, such as attaching a
name to a face, the name becomes a principal.
An authentication service is concerned with assuring that the communication
is authentic. In the case of a single message, such as warning or alarm signal, the
function of the authentication service is to assure the recipient that the message is
from the source that it claims to be from. In the case of an ongoing interaction, such
as the connection of a terminal to a host, two aspects are involved. First, at the time of
connection initiation, the service assures that the two entities are authentic, that is, that
each is the entity that it claims to be. Second, the service must assure that the
connection is not interfered with in such a way that a third party can masquerade as
one of the two legitimate parties for the purpose of unauthorized transmission or
reception.
Authorization
The process by which a user is given access to a system resource is known as
authorization. The authorization process is the check by the organization’s system to
see whether the user should be granted access to the user’s record. The user has
logged in to the system, but he still may not have the permission necessary from the
system to access the records.
When deploying a system, access to system resources should also be
mapped out. Security documents that detail the rights of individuals to specific
3
resources must be developed. These documents must distinguish between the owners
and the users of resources as well as read, write, delete, and execute privileges.
Confidentiality
Confidentiality is the protection of transmitted data from passive attack. With

respect to the release of message contents, several levels of protection can be
identified. The broadest service protects all user data transmitted between two users
over a period of time. Narrower forms of this service can also be defined, including
the protection of single message or even a specific field within a message. The other
aspect of confidentiality is the protection of traffic flow from analysis. This requires
the prevention of the attacker from observing destination, frequency, length, or other
characteristics of the traffic on a communications facility.
When the information is in a protected form, it is called a cipher text. Cipher

text uses a cipher, which changes the plaintext into cipher text. The cipher requires
keys to change the information from one form to the other.
Integrity
During the transmission or storage of data, information can be corrupted or
changed, maliciously or otherwise, by a user. Validation is the process of ensuring
data integrity. When data has integrity, it means that the data has not been modified or
corrupted. One technique for ensuring data integrity is called data hashing.
Integrity can apply to a stream of messages, a single message, or selected

fields within a message. Again the most useful and straightforward approach is total
stream protection. A connection-oriented integrity service, one that deals with a
stream of messages, assures that messages are received as sent, with no duplication,
insertion, modification, reordering or replay. The destruction of data is also covered
under this service. Thus, the connection-oriented integrity service addresses both
message stream modification and denial of service. On the other hand, a connection-
less integrity service, one that deals with individual messages only without regard to
any larger context, generally provides protection against message modification only.
4
Non-repudiation
Non repudiation prevents either sender or receiver from denying a transmitted

message. Thus, when a message is sent, the receiver can prove that the message was
in fact sent by the alleged sender. Similarly, when a message is received, the sender
can prove that the message was in fact received by the alleged receiver. In other
words, non-repudiation of origin proves that data has been sent, and non-repudiation
of delivery proves it has been received.
Access Control
Access control is the ability to limit and control the access to host systems and
applications links. To achieve this control, each entity trying to gain access must first
be identified, or authenticated. The goal of access control is to be able to specify and
restrict access to subjects and resources to those users and processes which have the
appropriate permission. Access control is implemented according to a policy that
defines methods for both authentication and authorization, and applies to a security
domain.
Availability
A variety of attacks can result in a form of reduction in availability. Some of

these attacks are amenable to automated countermeasures, such as authentication and
encryption, whereas others require some sort of physical action to prevent or recover
from loss of availability of elements of a distributed system.
5
1.3 SECURITY MECHANISM

A mechanism that is designed to detect, prevent, or recover from a security
attack. No single mechanism will support all required functions. Cryptography is one
of the security mechanisms. Some of the common security mechanisms are:
• Encryption
• Digital padding
• Traffic padding
• Routing control
• Trusted functionality
• Security labels
• Access controls
• Event detection
• Audit trials
1.4 SECURITY ATTACKS

Any action that compromises security of information is called a security attack. Some
of the common security attacks are given below.
6
Ref: http://www.cse.ohio-state.edu/~anish/694KNotes/694Lecture0.ppt#473,9,Security Attacks
Attacks can be active or passive

Passive Attacks
• Learn or make use of information from system, but does not affect system
resources.
• Intercept or read data without changing it.
• Goal of opponent is to obtain information that is being transmitted.
• This type of attack has been perpetrated against communication systems ever
since the invention of the electric telegraph.
• Two types of passive attacks are release of message contents and traffic
analysis (masking the content of message. e.g. Encryption).
• Difficult to detect, because no alteration of data. Normally done using
encryption.
Active Attacks
• Involve modification of data stream or creation of a false stream.

• The active threat is potentially far more serious.
• Use of encryption can protect against alteration of the data by arranging that
the encrypted data is structured in such a way that meaningful alteration
cannot take place without cryptanalysis.
7
• Subdivided into four categories: masquerade, replay, modification of

messages, and denial of service.
Masquerade: One entity pretends to be a different entity. e.g., Authentication

sequences can be captured and replayed after a valid authentication sequence
takes place.
Replay: Passive capture of data unit and its subsequence retransmission to produce
an unauthorized effect.
Modification of message: Some portion of message altered, or delayed or

reordered.
Denial of Service: Prevents normal use or management of communication

facilities.
e.g., suppressing all messages directed to a particular destination.
Other active attacks include:

• Flooding
• Jamming
• Routing attacks: False routes, Configuration changes
• Trap doors, Logic bombs etc,
• Remote arbitrary code execution via, worms and viruses.
1.5 HACKERS AND CRACKERS
A hacker (also called a White Hat) is often someone who creates and modifies
computer software and computer hardware, including computer programming,
administration, and security-related items. A hacker is also someone who modifies
electronics, for example, ham radio transceivers, printers or even home sprinkler
systems to get extra functionality or performance. A hacker obtains advanced
knowledge of operating systems and programming languages. They may know the
holes within systems and the reasons for such holes. Hackers constantly seek further
8
knowledge, freely share what they have discovered, and never, ever intentionally
damage data.
For further reading: http://en.wikipedia.org/wiki/Hacker

http://catb.org/~esr/faqs/hacker-howto.html
A cracker (also called a Black Hat) is a person who uses their skills with computers
and other technological items in a malicious or criminal manner. He breaks into or
otherwise violates the system integrity of remote machines, with malicious intent.
Crackers, having gained unauthorized access, destroy vital data, deny legitimate users
service, or basically cause problems for their targets. Usually a Black Hat is a person
who uses their knowledge of vulnerabilities and exploits for private gain, rather than
revealing them either to the general public or the manufacturer for correction.
For further reading: http://en.wikipedia.org/wiki/Cracker_%28computing%29
1.6 COMMON INTRUSION TECHNIQUES
Virus
In computer security technology, a virus is a self-replicating program that
spreads by inserting copies of itself into other executable code or documents. A virus
is a program that can copy itself and infect various parts of your computer, such as
documents, programs, and parts of your operating system. Most viruses attach
themselves to a file or part of your hard disk and then copy themselves to other places
within the operating system. Some viruses contain code that inflicts extra damage by
deleting files or lowering your security settings, inviting further attacks. Usually to
avoid detection, a virus disguises itself as a legitimate program that a user would not
normally suspect to be a virus. Viruses are designed to corrupt or delete date on the
hard disk, i.e. on the FAT (File Allocation Table).
A computer virus behaves in a way similar to a biological virus, which

spreads by inserting itself into living cells. Extending the analogy, the insertion of the
virus into a program is termed infection, and the infected file (or executable code that
is not part of a file) is called a host. Viruses are one of the several types of malware or
9
malicious software. Computer viruses cannot directly damage hardware, only

software is damaged directly. The software in the hardware however may be
damaged.
TYPES OF VIRUSES
System or Boot Sector Virus
System sectors are special areas on the disk containing programs that
are executed when we boot (start) the PC. Every disk (even if it only contains data)
has a system sector of some sort. System sector viruses infect executable code found
in certain system areas on a disk. There are boot-sector viruses, which infect only the
DOS boot sector, this kind of virus can prevent us from being able to boot the hard
disk. All common boot sector and MBR viruses are memory resident. System sector
viruses spread easily via floppy disk infections and, in some cases, by cross infecting
files which then drop system sector viruses when run on clean computers.
File or Program Virus

These viruses infect applications. These viruses usually infect COM
and/or EXE programs, though some can infect any program for which execution or
interpretation is requested, such as SYS, OVL, OBJ, PRG, MNU and BAT files. The
simplest file virus work by locating a type of file they know how to infect (usually a
file name ending in .COM or .EXE) and overwriting part of the program they are
infecting. When this program is executed, the virus code executes and infects more
files. The more sophisticated file viruses save (rather than overwrite) the original
instructions when they insert their code into the program. This allows them to execute
the original program after the virus finishes so that everything appears normal.
File viruses have a wide variety of infection techniques and infect a
large number of file types, but are not the most widely found in the wild.
Macro Virus
These are the most common viruses striking computers today. While some can
be destructive, most just do annoying things, such as changing your word processing
documents into templates or randomly placing a word such as "Wazoo" throughout a
document. While these actions may not permanently damage data, they can hurt
10
productivity. The reasons these viruses have become so widespread, and the reasons
they are so troublesome, are twofold: They are easy to write, and they exist in
programs created for sharing.
It is a program or code segment written in the internal macro language of an
application and attached to a document file (such as Word or Excel). It infects files
you might think of as data files. But, because they contain macro programs they can
be infected.
When a document or template containing the macro virus is opened in the
target application, the virus runs, does its damage and copies itself into other
documents. Continual use of the program results in the spread of the virus. Some
macros replicate, while others infect documents.
Stealth Viruses
These viruses are stealthy in nature and use various methods to hide
themselves to avoid detection. They sometimes remove themselves from the memory
temporarily to avoid detection and hide from virus scanners. Some can also redirect
the disk head to read another sector instead of the sector in which they reside. Some
stealth viruses conceal the increase in the length of the infected file and display the
original length by reducing the size by the same amount as that of that of the increase,
so as to avoid detection from scanners, making them difficult to detect.
Polymorphic Viruses
They are the most difficult viruses to detect. They have the ability to
mutate implying that they change the viral code known as the signature (A signature
is a characteristic byte-pattern that is part of a certain virus or family of viruses) each
time they spread or infect. Thus, anti-viruses which look for specific virus codes are
not able to detect such viruses. Just like regular encrypted viruses, a polymorphic
virus infects files with an encrypted copy of itself, which is decoded by a decryption
module. In the case of polymorphic viruses however, this decryption module is also
modified on each infection. A well-written polymorphic virus therefore has no parts
that stay the same on each infection, making it impossible to detect directly using
signatures.
11
Examples
Brain virus
The first computer virus for Microsoft DOS was apparently written in 1986
and contains unencrypted text with the name, address, and telephone number of Brain
Computer Services, a store in Lahore, Pakistan. This virus infected the boot sector of
5¼ inch floppy diskettes with a 360 Kbyte capacity.
Pathogen Virus
In April 1994, the Pathogen computer virus was released in the

United Kingdom, by uploading an infected file to a computer bulletin board, where
victims could download a copy of the file.
The Pathogen virus counted the number of executable (e.g., *.EXE and *.COM)
files that it infected. When the virus had infected 32 files and an infected file was
executed between 17:00 and 18:00 on a Monday:
For further reading: http://en.wikipedia.org/wiki/Computer_virus

http://www.webopedia.com/TERM/v/virus.html
Worm
A worm is a self-replicating computer program. It uses a network to
send copies of itself to other nodes (computer terminals on the network) and it may do
so without any user intervention. A worm is self-contained and unlike a virus, it does
not need to be part of another program to propagate itself. They are often designed to
exploit the file transmission capabilities found on many computers.Worms always
harm the network (if only by consuming bandwidth), whereas viruses always infect or
corrupt files on a targeted computer.
12
In addition to replication, a worm may be designed to do any number of

things, such as delete files on a host system or send documents via email. More recent
worms may be multi-headed and carry other executables as a payload. However, even
in the absence of such a payload, a worm can wreak havoc just with the network
traffic generated by its reproduction.
For further reading: http://en.wikipedia.org/wiki/Computer_worm

http://www.webopedia.com/TERM/w/worm.html
Trojan horse
A Trojan horse is a program that masquerades as another common
program in an attempt to receive information. It is a harmless-looking program
designed to trick you into thinking it is something you want, but which performs
harmful acts when it runs. It is typically received through downloads from the
Internet. Trojan horses do not spread by themselves like viruses and worms. In
practice, Trojan Horses in the wild often contain spying functions or backdoor
functions that allow a computer, to be remotely controlled from the network, creating
a zombie computer.
There are two common types of Trojan horses. One, is otherwise
useful software that has been corrupted by a cracker inserting malicious code that
executes while the program is used. Examples include various implementations of
weather alerting programs, computer clock setting software, and peer to peer file
sharing utilities. The other type is a standalone program that masquerades as
something else, like a game or image file, in order to trick the user into some
misdirected complicity that is needed to carry out the program's objectives.
The basic difference from computer viruses is: a Trojan horse is technically a
normal computer program and does not possess the means to spread itself. Originally
Trojan horses were not designed to spread themselves. They relied on fooling people
to allow the program to perform actions that they would otherwise not have
voluntarily performed. Trojans of recent times also contain functions and strategies
that enable their spreading. This moves them closer to the definition of computer
viruses, and it becomes difficult to clearly distinguish such mixed programs between
Trojan horses and viruses.
13
Probably the most famous Trojan horse is a program called "back orifice"
which is an unsubtle play on words on Microsoft's Back Office suite of programs for
NT server. This program will allow anybody to have complete control over the
computer or server it occupies.
For further reading: http://en.wikipedia.org/wiki/Trojan_horse_(computing)

http://www.webopedia.com/TERM/T/Trojan_horse.html
Logic Bomb
A logic bomb is a piece of code intentionally inserted into a software
system that will set off a malicious function when specified conditions are met. They
are viruses having a delayed payload, which is sometimes called a bomb. For
example, a virus might display a message on a specific day or wait until it has
infected a certain number of hosts. A logic bomb occurs when the user of a computer
takes an action that triggers the bomb.
For further reading: http://en.wikipedia.org/wiki/Logic_bomb
14
Unit 2
2.1 OS SECURITY
File systems often contain information that is highly valuable to their users. Protecting
this information against unauthorized usage is therefore a major concern of all file
systems. Various issues concerned with security and protection are given below:
2.1.1 The Security Environment:
The terms Security and Protection are often used interchangeably. Security refers to
the overall problem involved in preventing unauthorized reads or modifications,
which include technical, managerial, legal, and political issues. Protection refers to
the specific operating system mechanisms used to safeguard information in the
computer.
The two important facets of Security are Data Loss and Intruders.
Data Loss is mainly caused by
1. Acts of God (fires, floods, earthquakes)

2. Hardware or Software errors (CPU malfunctions, unreadable disks or tapes,
telecommunication errors, program bugs)
3. Human Errors (incorrect data entry, wrong tape or disk mounted, wrong
program run, lost disk or tape).
Intruders come in 2 varieties:
1. Passive Intruders who read files they are not authorized to read.
2. Active Intruders who make unauthorized changes to data.
15
Another aspect of Security problem is Privacy: protecting individuals from misuse of

information about them.
2.1.2 The Internet Worm:
The greatest computer security violation began in the form of a worm program. A
WORM is a self replicating program that replicates itself in seconds on every machine
it could gain access to.
2.1.3 Generic Security Attacks:
Viruses:
A Virus is a program fragment that is attached to a legitimate program with the

intention of infecting other programs. It differs from a worm only in that a virus
piggybacks on an existing program, whereas a worm is a complete program in itself.
Viruses and worms both attempt to spread themselves and both can do severe damage.
In addition to just infecting other programs, a virus can erase, modify, or encrypt files.
It is also possible for a virus to infect the hard disk’s boot sector, making it impossible
to boot the computer.
Virus problems are easier to prevent than to cure. The safest course is only to buy
shrink-wrapped software from respectable stores and to avoid uploading free software
from bulletin boards or getting pirated copies on floppy disk.
2.1.4 Design Principles for Security:
Viruses mostly occur on desktop systems. On larger systems other problems occur
and other methods are needed for dealing with them.
Some general principles that can be used as a guide to designing secure systems have
been identified by Saltzer and Schroeder. They are:
16
i. The system design should be public - Assuming that the intruder will not
know how the system works serves only to delude the designers.
ii. The default should be no access - Errors in which legitimate access is refused
will be reported much faster than errors in which unauthorized access is
allowed.
iii. Check for current authority - Many systems check for permission when a file
is opened, and not afterward. This means that a user who opens the file, and
keeps it open for weeks, will continue to have access, even if the owner has long
since changed the file protection.
iv. Give each process the least privilege possible - If an editor has only the access
the file to be edited, editors with Trojan horses will not be able to do much
damage.
v. The protection mechanism should be simple, uniform and built in to the

lowest layers of the system - Trying to retrofit security to an existing insecure
system is nearly impossible. Security is not an add-on feature.
vi. The Scheme chosen must be psychologically acceptable - If users feel that
protecting their files is too much work, they just will not do it.
2.1.5 User Authentication:
The problem of identifying users when they log in is called user authentication.
Most authentication methods are based on identifying something the user knows,
something the user has, or something the user is.
Passwords:
The most widely used form of authentication is to require the user to type a password.
Password protection is easy to implement and easy to understand. Password
17
protection is also easy to defeat. Guessing a user name and password combination
constitutes the break-in all the time virtually.
Some computers require users to change their passwords regularly, to limit the
damage done if a password leaks out. The most extreme form of this approach is the
One-Time Password. When one-time passwords are used, the user gets a book
containing a list of passwords. Each login uses the next password in the list. If an
intruder ever discovers a password, it won’t be of any good, since next time a
different password must be used. It is suggested that the user try to avoid losing the
password book.
Another variation is Challenge-Response. When this is used, the user
picks an algorithm when signing up as a user, for example 2x. When the user logs in,
the computer types an argument, say 7, in which case the user types 14. The algorithm
can be different on different days of the weeks, at different times, from different
terminals, and so on.
Physical Identification:
This approach checks whether the user has some item, normally a plastic card
with a magnetic stripe on it. The card is inserted into the terminal, which then checks
to see whose card is it. This method can be combined with a password, so a user can
only log in if he has the card and knows the password. Automated cash-dispensing
machines usually work this way. To measure physical characteristics that are hard to
forge is another method. For example, a fingerprint or a voiceprint reader in the
terminal could identify the user’s identity.
Another technique is Signature Analysis, where the user signs his name
with a special pen connected to the terminal, and the computer compares it to a known
specimen stored on line. Even better is not to compare the signature, but compare the
pen motions while writing it. A good forger may be able to copy the signature, but
will not have a clue as to the exact order in which the strokes were made.
In Finger Length Analysis, each terminal has a device similar to the palm.
The user inserts his hands into it, and the length of all his fingers is measured and
checked against the database.
2.2 PROTECTION MECHANISMS
Some of the detailed technical ways that are used in operating systems to protect files
and other things are discussed here. All these techniques clearly distinguish between
18
policy and mechanism. POLICY involves whose data are to be protected from whom
and MECHANISM involves how the system enforces the policy.
2.2.1 Protection Domains
A computer system contains many OBJECTS that need to be protected. These objects
can be hardware such as CPUs, memory segments, terminals, disk drives or printers
or they can be Software such as processes, files, data bases, or semaphores. Each
object has a unique name by which it is referenced and a set of operations that can be
carried out on it. READ and WRITE operations appropriate to a file; UP and DOWN
make sense on semaphore.
Protection mechanism is a way used to prohibit processes from
accessing objects that they are not authorized to access. This mechanism should also
restrict processes to a subset of the legal operations when that is needed. For example
process A may be entitled to read, but not write, file F.
A DOMAIN is a set of (object, rights) pairs. Each pair specifies an object and
some subset of the operations that can be performed on it. A RIGHT here means
permission to perform one of the operations.
Domain 1 Domain 2 Domain 3
File3[R]
File1[R] File4[RWX]
File2 [RW] File6[RWX]
Printer1[W]
Plotter2[W]
File5[RW]
Fig 2.1: Three Production Domains.
The above figure depicts 3 domains, showing the objects in each domain and the
rights [Read, Write, execute] available on each object. Printer1 is in 2 domains at
the same time.
It is also possible for the same object to be in multiple domains, with different
rights in each domain. At every instant of time, each process runs in some
19
protection domain. In other words, there is some collection of objects it can

access, and for each object it has some set of rights. Processes can also switch
from domain to domain during execution. The rules for domain switching are
highly system dependent.
Example:
In UNIX, the domain of a process is defined by its uid and gid. Given any (uid,
gid) combination, it is possible to make a complete list of objects (files, including
I/O devices represented by special files, etc) that can be accessed, and whether
they can be accessed for reading, writing, or executing. 2 processes with same
(uid, gid) combination will have access to exactly the same set of objects.
Processes with different (uid, gid) values will have access to a different set of
files, although there will be considerable overlap in most cases.
Each process in UNIX has 2 halves: the USER part and the
KERNEL part. When the process does a system call, it switches from the user part
to the kernel part. The kernel part has access to a different set of objects from the
user part. For example, the kernel can access all the pages in physical memory, the
entire disk, and all the other protected resources. Thus, a system call causes a
domain switch.
Protection Matrix:
This is used to know how the system keeps track of which object belongs to which
domain. Imagine a large matrix, with the rows being the domains and the columns
being the objects. Each box lists the rights, if any, that the domain contains for the
object.
The matrix for the first figure (3 protection domains) is shown below:
20
Domai Object
n
File 1 File 2 File 3 File 4 File 5 File 6 Printer 1 Plotter 2
1 Read Read
Write
Read
2 Read Write Read Write
Execute Write
Read
3 Write Write Write
Execut
e
Fig 2.2: A Protection Matrix.
Given this matrix and the current domain number, the system can tell if
an access to given object in a particular way from a specified domain is allowed.
Domain switching itself can be easily included in the matrix model by realizing that a
domain is itself an object, with the operation ENTERS. The figure below shows the
matrix of the above figure again, only now with the three domains as objects
themselves. Processes in domain 1 can switch to domain 2, but once there, they
cannot go back.
21
Domai Object
n
File File File File File File Printe Plotte D1 D2 D3

1 2 3 4 5 6 r r2
1
Enter
1 R R
W
R
2 R W R W
X W
R
3 W W W
X
Fig 2.3: A protection matrix with domains as objects.
Storing very large and sparse matrices are rarely done in practice. Most domains have
no access at all to most objects, so storing a big, empty matrix is a waste of disk
space. 2 methods used practically are storing the matrix by rows or by columns, and
then storing only the nonempty elements.
Storing by columns:
It consists of associating with each object an (ordered) list containing all the domains
that may access the object. This list is called the Access Control List or ACL. As
only the nonempty entries of the matrix are stored, the total storage required for all the
ACLs combined is much less than would be needed for the whole matrix.
The owner of an object can change its ACL at any time, thus making it easy
to prohibit accesses that were previously allowed. The only problem is that changing
the ACL will probably not affect any users who are currently using the object (e.g.,
have the files open).
22
Storing by rows:
It is the slicing up the matrix by rows. Here, associated with each process is a list of
object that may be accessed, along with an indication of which operations are
permitted on each (its domain). This list is called a Capability List or C-lists, and the
individual items on it are called Capabilities.
A typical capability list is shown below:
Type RightsObject
O File R-- Pointer to File3
1 File RWX Pointer to File4
2 File RW- Pointer to File5
3 Printer -W- Pointer to Printer1
Each capability has a:
Type field ------> specifies what kind of object it is,

Rights field-----> which is a bit map indicating which of the legal operations on this
type of object are permitted.
Object field-----> which is a pointer to the object itself.
C-lists are themselves objects, and may be pointed from other C-lists, thus facilitating
sharing of sub domains. Capabilities are often referred to by their position in the
capability list. C-lists must be protected from user tampering. 3 methods have been
proposed to protect them:
1. The first way requires a tagged architecture, a hardware design in which each
memory word has an extra (or tag) bit that tells whether the word contains a capability
or not. The tag bit is not used by arithmetic, comparison, or similar ordinary
instructions and it can be modified only by programs running in the kernel mode (i.e.,
the operating system).
23
2. The second way is to keep the C-list inside the operating system, and just have
processes refer to capabilities by their slot number.
3. The third way is to keep the C-list in user space, but encrypt each capability with a
secret key unknown to the user. This approach is particularly suited to distributed
systems.
In addition to the specific object-dependent rights, such as read and execute,
capabilities usually have generic rights which are applicable to all objects. Examples
of generic rights are:
a. COPY CAPABILITY: create a new capability for the same object.

b. COPY OBJECT: create a duplicate object with a new capability.
c. REMOVE CAPABILITY: delete an entry from the C-list; object
unaffected.
d. DESTROY OBJECT: permanently remove an object and a capability.
Many capability systems are organized as a collection of modules, with type

manager modules for each type of object. Requests to perform operations on a file
are sent to the file manager, whereas requests to do something with a mailbox go to
the mailbox manager. These requests are accompanied by the relevant capability. A
problem arises here, because the type manager module is just an ordinary program,
after all. The owner of a file capability can perform only some of the operations on
the file, but cannot get at its internal representation. It is necessary that the type
manager module be able to do more with the capability than an ordinary process.
Hydra solved this problem by a technique called rights amplification, in which type
managers were given a rights template that gave them more rights to an object than
the capability itself allowed.
In Capability systems, revoking access to an object is quite difficult. It
is hard for the system to find all the outstanding capabilities for any object to take
them back, since they may be stored in C-lists all over the disk. One approach is to
have each capability point to an indirect object, rather than to the object itself. By
having the indirect object point to the real object, the system can always break that
connection, thus invalidating the capabilities. (When a capability to the indirect object
is later presented to the system, the user will discover that the indirect object is now
pointing to a null object.)
24
Amoeba uses another scheme to achieve revocation. Each object contains

a long random number, which is also present in the capability. When a capability is
presented for use, the two are compared. Only if they agree, is the operation allowed.
The owner of an object can request that the random number in the object be changed,
thus invalidating existing capabilities. Neither scheme allows selective revocation,
that is, taking back only one’s permission, but nobody else’s.
2.2.2. Protection Models
Protection matrices are not static. They frequently change as new objects are created,
old objects are destroyed, and owners decide to increase or restrict the set of users for
their objects.
There are 6 primitive operations on the protection matrix that can be
used as a base to model any protection system. These operations are: CREATE
OBJECT, DELETE OBJECT, CREATE DOMAIN, DELETE DOMAIN, INSERT
RIGHT, and REMOVE RIGHT. The 2 latter primitives insert and remove rights from
specific matrix elements. These 6 primitives can be combined into protection
commands. User programs execute these protection commands to change the matrix.
They may not execute the primitives directly. At any instant, the matrix determines
what a process in any domain can do, not what it is authorized to do. The matrix is
what is enforced by the system; authorization has to do with management policy.
Example:
25
Consider the simple system below, where domains correspond to user.
Objects Objects
Compiler Mailbox7 Secret Compiler Mailbox7 Secret

Eric Read Eric Read
Execute Execute
Henry Read Read Henry Read Read
Execute Write Execute Write
Robert Read Read Robert Read Read Read
Execute Write Execute Write
Fig: (a) An authorized state. (b) An unauthorized state.
In the figure (a) the intended protection policy is seen: Henry can read and write
mailbox7, Robert can read and write secret, and all the 3 can read and execute
compiler.
If Robert found a way to issue commands and have the matrix changed to
figure (b); then he can access mailbox7, something he is not authorized to have. If he
tries to read it, the operating system will carry out his request because it does not
know that the state is an unauthorized one.
The set of all possible matrices can be partitioned into 2 disjoint sets:
a. The set of all authorized states, and
b. The set of all unauthorized states.
The security policy enforced by the protection commands has 2 rules:
1. No process may read any object whose level is higher that its own, but it may
freely read objects at a lower level or at its own level. A secret process may
read confidential objects, but not top secret ones.
2. No process may write information into any object whose level is lower than its
own. A secret process may write in a top secret file but not in a confidential
one.
26
2.2.3. Covert Channels
To make formal models for protection systems is much futile. Even in a system that
has been rigorously proven to be absolutely secure, leaking information between
processes that in theory cannot communicate at all is relatively straightforward.
Lampson proposed a model which involves 3 processes, and is primarily applicable

to large time sharing systems. The first process is a Client, which wants some work
performed by the second one, the Server. The client and the server do not entirely
trust each other. The third process is the Collaborator, which is conspiring with the
server to indeed steal the client’s confidential data. The collaborator and server are
typically owned by the same person. These 3 processes are shown in the figure below:
Client
Encapsulated
Server server
Collaborator
Covert
Channel
Kernel Kernel
The object here is to design a system in which it is impossible for the server to leak to
the collaborator the information that it has legitimately received from the client.
Lampson called this the confinement problem.
From the system designer’s point of view, the goal is to encapsulate or

confine the server in such a way that it cannot communicate with the collaborator by
writing into a file to which the collaborator has read access. It is also necessary to
ensure that the server cannot communicate with the collaborator by using the system’s
27
inter-process communication mechanism. But more subtle communication channels

may be available.
For example, the server can try to communicate a binary bit stream as
follows. To send a 1 bit, it computes as hard as it can for a fixed interval of time. To
send a 0 bit, it goes to sleep for the same length of time. The collaborator can try to
detect the bit stream by carefully monitoring its response time. In general, it will get
better response time when the server is sending a 1. This communication channel is
known as a covert channel.
The covert channel is a noisy channel, containing a lot of extraneous

information. But information can be reliably sent over a noisy channel by using an
error-correcting code (e.g. a hamming code). The use of an error-correcting code
reduces the already low bandwidth of the covert channel even more, but it still may be
enough to leak substantial information. No protection model based on a matrix of
objects and domains can prevent this kind of leakage.
Modulating the CPU usage is not only the covert channel. The paging
rate can also be modulated (many page faults for a 1, no page faults for a 0). Almost
any way of degrading system performance in a clocked way is a candidate. If the
system provides a way of locking files, then the server can lock some file to indicate a
1, and unlock it to indicate a 0. It may be possible to detect the status of a lock even
on a file that cannot be accessed.
Acquiring and releasing dedicated resources (tape drives, plotters, etc) can
also be used for signaling. The server acquires the resource to send a 1 and releases it
to send a 0. But, even finding all the covert channels, let alone blocking them, is
extremely difficult.
2.3. DAC (Discretionary Access Control)
One of the features of the Criteria that are required of a secure system is the
enforcement of discretionary access control (DAC). DAC is a means of restricting
28
access to objects based on the identity of subjects and/or groups to which they belong.
The controls are discretionary in the sense that a user or process given discretionary
access to information is capable of passing that information along to another subject.
Discretionary control is the most common type of access control mechanism

implemented in computer systems today. The basis of this kind of security is that an
individual user, or program operating on the user's behalf, is allowed to specify
explicitly the types of access other users (or programs executing on their behalf) may
have to information under the user's control. Discretionary security differs from
mandatory security in that it implements the access control decisions of the user.
Mandatory controls are driven by the results of a comparison between the user's trust
level or clearance and the sensitivity designation of the information.
Discretionary controls are not a replacement for mandatory controls. In any

environment in which information is protected, discretionary security provides for a
finer granularity of control within the overall constraints of the mandatory policy.
Both discretionary and mandatory controls can be used to implement an access
control policy to handle multiple categories or types of information, such as
proprietary, financial, personnel or classified information. Such information can be
assigned different sensitivity designations and those designations enforced by the
mandatory controls. Discretionary controls can give a user the discretion to specify
the types of access other users may have to information under the user's control,
consistent with the overriding mandatory policy restrictions. In a classified
environment, no person may have access to classified information unless: (a) that
person has been determined to be trustworthy, i.e., granted a personnel security
clearance - MANDATORY, and (b) access is necessary for the performance of
official duties, i.e., determined to have need-to-know - DISCRETIONARY.
The discretionary security control objective is: Security policies defined for systems
that are used to process classified or other sensitive information must include
provisions for the enforcement of discretionary access control rules. That is, they must
include a consistent set of rules for controlling and limiting access based on identified
users who have been determined to have need-to-know for the information.
DEFINITIONS
29
Discretionary Access Control (DAC)-The Criteria defines discretionary access control

as: “A means of restricting access to objects based on the identity of subjects and/or
groups to which they belong. The controls are discretionary in the sense that a subject
with certain access permission is capable of passing that permission (perhaps
indirectly) on to any other subject.”
DAC controls are used to restrict a user's access to protected objects on the system.
The user may also be restricted to a subset of the possible access types available for
those protected objects. Access types are the operations a user may perform on a
particular object (e.g., read, write, execute). Typically, for each object, a particular
user or set of users has the authority to distribute and revoke access to that object.
Users may grant or rescind access to the objects they control based on "need to know"
or "whom do I like" or other rules. DAC mechanisms control access based entirely on
the identities of users and objects.
The identity of the users and objects is the key to discretionary access control. This
concept is relatively straightforward in that the access control matrix contains the
names of users on the rows and the names of objects on the columns. Regardless of
how the matrix is represented in memory, whether by rows or by columns, the names
of the users and objects must be used in the representation. For example, in a row-
based representation an entry might read the equivalent of “KIM can access
KIMSFILE and DONSFILE". In a column based representation, one might find the
equivalent of "DONSFILE can be accessed by DON, JOE and KIM".
AN INHERENT DEFICIENCY IN DISCRETIONARY ACCESS CONTROL
A FUNDAMENTAL FLAW IN DISCRETIONARY ACCESS CONTROL
Discretionary access control mechanisms restrict access to objects based solely on the
identity of subjects who are trying to access them. This basic principle of
discretionary access control contains a fundamental flaw that makes it vulnerable to
Trojan horses. On most systems, any program which runs on behalf of a user inherits
30
the DAC access rights of that user. An example of the workings of a Trojan horse will
illustrate how most DAC mechanisms are vulnerable.
AN EXAMPLE OF A TROJAN HORSE
Consider a system where an access control list mechanism is used to implement

discretionary access control. There are two users on this particular system: an honest
user, DOE; and a dishonest user, DRAKE. Doe has a data file which contains highly
sensitive data; this file is known as DOESFILE. He has diligently set the ACL to
allow only himself to read the file. No other users are authorized to access the file.
Doe is confident that no one but himself will be able to access his data file. Drake is
determined to gain access to DOESFILE. He has legitimate access to the system
which allows him to implement a useful utility program. In this utility Drake embeds
a covert function to read DOESFILE and copy the contents into a file in Drake’s
address space called DRAKESFILE. DRAKESFILE has an ACL associated with it
that allows processes executing on Doe’s behalf to write to it, while allowing Drake’s
processes to read it. Drake induces Doe to execute his utility program by telling him
how useful and efficient it is. Drake is careful not to tell Doe about the covert function
(Trojan horse) that is resident in the utility program. Doe executes the corrupted
program and it appears to perform perfectly. However, while it is operating on Doe's
behalf, it assumes his identity and thus his access rights to DOESFILE. At this time it
copies the contents of DOESFILE to DRAKESFILE. This copying takes place
completely within the constraints of the DAC mechanism, and Doe is unaware of
what is happening. This example should make clear the danger of Trojan horse attacks
and the inadequacy of most DAC mechanisms to protect against such attacks. It
should be noted that an elaborate DAC mechanism may provide illusory security to
users who are unaware of its vulnerability to Trojan horse attacks.
Configuration management, testing, and trusted distribution should ensure that

software produced by the computer system manufacturer does not contain Trojan
horses, especially if the system has a high EPL rating. However, software from other
sources does not come with these assurances. In very high threat environments, it is
wise to assume that unevaluated software does contain Trojan horses. This
assumption dictates that discretionary access control not be used as the sole protection
31
mechanism in high threat environments. The Trojan horse threat can be reduced in
systems that implement many domains or dynamic small domains for each process. In
most systems today, with only user and supervisor domains, all of the user's objects
are available to a process running on that user's behalf. If domains were created
dynamically for each process, with only the necessary objects available, in that
domain (implementing the least privilege principle), then a Trojan horse would be
limited to accessing only those objects within the domain.
A reference monitor which implements a mandatory security policy which includes

the *-property would provide robust protection against Trojan horse attacks. The
mandatory access control implementation would prevent the Trojan horse from
disclosing the information to a user who is not permitted access to the information
under the mandatory access rules. The computer system implements a mandatory
security policy with two hierarchical sensitivity levels. For the sake of simplicity, the
levels are called sensitive and non-sensitive. DOE operates at the sensitive level, and
DOESFILE is sensitive. DRAKE is not authorized to access sensitive data, so he
operates at the non-sensitive level. DRAKE is only allowed to read non-sensitive
files, so DRAKESFILE is nonsensitive. As before, Drake’s Trojan horse program is
executed by DOE. The program takes on the sensitivity level and the identity of DOE.
Within the constraints of the mandatory and the discretionary security policies, the
program reads DOESFILE. However, when the Trojan horse tries to write the
sensitive data to DRAKESFILE, the reference monitor disallows the operation. Since
the Trojan horse is no w executing at the sensitive level, the program cannot be
allowed to write to a non-sensitive file. That would be a violation of the *-property.
AN OVERVIEW OF DAC MECHANISMS
Implementing a complete DAC system requires retaining the information that is

represented by the access control matrix model in some form. An access control
matrix has users represented on the rows and protected objects on the columns. The
entries in the matrix describe what type of access each user has to each object. Current
operating systems have attempted to represent that information using five basic
mechanisms:
1. Capabilities
32
2. Profiles
3. Access Control Lists (ACLs)
4. Protection Bits
5. Passwords
CAPABILITIES
In a capability-based system, access to protected objects such as files is granted if the

would- be accessor possesses a capability for the object. The capability is a protected
identifier that both identifies the object and specifies the access rights to be allowed to
the accessor who possesses the capability. Two fundamental properties of capabilities
are that they may be passed from one accessor (subject) to another and that the
accessor who possesses capabilities may not alter or fabricate capabilities without the
mediation of the operating sys tem TCB.
Capability-based systems provide dynamically changeable domains (name
spaces) for processes to run in. Ability to access an object is demonstrated when a
process has a capability or “ticket” to the object. The capability also contains
allowable access modes (e.g., read, write, execute). In some implementations,
programs can contain capabilities or capabilities can be stored in files. They are
protected by hardware and software mechanisms or by encryption. Capabilities can
usually be passed along to other processes and can sometimes be increased or
decreased in scope.
A pure capability system includes the ability for users to pass the capability to other
users. Because this ability is not controlled and capabilities can be stored, determining
all the users who have access for a particular object generally is not possible. This
makes a complete DAC implementation, including revocation, very difficult.
(Revocation may not be an issue, however, since a user who has access to an object
can make a copy of the information in another object. Revoking the user's access on
the original object does not revoke access to the information contained in the user's
copy. After revocation, however, changes can be made to the original object without
the knowledge of revoked users.)
33
Since capabilities implement dynamic domains they can ideally limit the objects
accessible to any program. This would limit a Trojan horse's access to only the
protected objects handed to it. At this time, few systems have been implemented with
capabilities and very few, if any, have attempted to implement a complete DAC
mechanism. Capabilities could be useful in enforcing the least privilege principle and
providing dynamically changeable domains, making discretionary access controls less
vulnerable to Trojan horse attacks.
PROFILES
Profiles which have been implemented in some form on several systems use a list of
protected objects associated with each user. Since object names are not consistent or
amenable to grouping, their size and number are difficult to reduce. If a user has
access to many protected objects, the profile can get very large and difficult to
manage. Also, all protected object names must be unique so full pathnames must be
used. Creating, deleting and changing access to protected objects requires many
operations since multiple users' profiles must be updated. Timely revocation of access
to an object is very difficult unless the user's profile is automatically checked each
time the object is accessed. Deleting an object may require some method of
determining every user who has the object in his profile. In general, with profiles as
with capabilities, answering the question of who has access to a protected object is
very difficult. Since this is usually an important question in a secure system and more
efficient mechanisms exist, profiles are not a recommended implementation of DAC.
ACCESS CONTROL LISTS (ACLs)
ACLs allow any particular user to be allowed or disallowed access to a particular

protected object. They implement the access control matrix b y representing the
columns as lists of users attached to the protected objects. The lists do not have to be
excessively long if groups and wild cards (see below) are used. The use of groups
raises the possibility of conflicts between group and individual user. As an example,
the ACL entries "PAYROL rw" and "Jones.PAYROL r" appear to conflict, but can be
resolved in the design of the DAC mechanism. The Apollo system has a multiple,
hierarchical group mechanism. The ACL entry has the form “user-
id.group.organization.node.” As in Multics, if the ACL specifies access rights for the
user by user-id then group access rights are ignored. This allows a particular user to
34
be excluded or restricted in access rights. In the Apollo, if a user is not on the ACL by
user-id, but is a member of a group, those rights are used and organization and node
memberships are not examined. Multiple group mechanisms add more complexity
and may facilitate administrative control of a system, but do not affect the utility of a
DAC mechanism.
Access to ACLs should be protected just as other objects are protected. The creation
of groups must be controlled, since becoming a member of a group can change the
objects accessible to any member. In many systems, e.g., Multics, a user must be a
member of at least one group. One detriment of the group mechanism is that changing
the members of a group results in changes to an unknown set of ACLs for protected
objects. Allocation of groups could be a Systems Administrator function only, or it
could be distributed to a Project Administrator type function. Problems could result
from allowing any user to create a group and then be "owner'' of that group. If users
were prohibited from listing the members of groups they are not in because of covert
channels and privacy, it would be difficult to determine if a group was the correct one
to use. System or Project Administrator control is a preferred mechanism.
Wild Cards
A wild card mechanism allows a string replacement where the wild card is specified.
For example, in the Multics system ```PAYROL rw'' gives read and write access to
any user in the PAYROL group. ``Smith.* r'' gives Smith read access, no matter what
group the user Smith belongs to. ``*.*'' gives any user access. The group and wild
card mechanisms allow the ACL list to be kept to a reasonable size. The use of wild
cards raises the possibility of conflicts if a user has multiple ACL entries for an
object. In the above example, Smith has a possible conflict; as a member of any group
he can read and as a member of the PAYROL group he can read and write. The
system must make a decision as to which one of the ACL entries it will apply when
granting Smith access to the object. Various systems have different rules for resolving
conflicts. One approach might be to have the system enforce an ordering of the ACLs.
Another approach might be to allow ordering of the ACLs by the users. In any case,
the users must understand the rules in order to create effective ACL entries. A wild
card mechanism adds more complexity, but does not affect the utility of a DAC
mechanism.
35
Default ACLs
There are many side issues in the implementation of access control lists. Default
ACLs are usually necessary for the user friendliness of the DAC mechanism. At the
very least, when an object is created by a user, the user should be placed on its ACL
by default. Some of the other possible default mechanisms include a system-wide
default, a user-associated default or if the file structure is a tree, a default associated
with the directory.
A system-wide default could be used as the default in cases where no other default
had been specified. A system-wide default might give access only to the creating user.
A user-associated default might work well on a system with a flat file structure. When
a user is first entered on the system, his default ACL would have to be specified. For
file structures that are trees, a default(s) associated with the directory could be most
efficient. If the user organizes the directory structure to represent project work or
areas of interest, then the ACLs for all objects in a sub -tree would be similar. One
default ACL in the directory would be for children that are files. For children that are
directories either a separate sub-directory default ACL should be specified or the
default ACLs should have to be stated explicitly by the user. Otherwise, unless care is
taken, those with access to the root sections of the storage hierarchy could by
automatic default get access to all of the storage hierarchy.
The overriding principle of least privilege implies that the use of defaults should not
inadvertently give away more access than the user intended. In other words, to err on
the conservative side is preferred. In all implementations some user(s) must have
permission to change the ACLs after they have been set by default, and the ability to
change the defaults is very useful. Defaults can be implemented in two ways: they can
be copied to the ACL or they can be pointed to by the ACL. If they are copied, then
changes to the default will not affect the ACL; otherwise, changes in the default may
cause changes in many ACLs.
Named ACLs
Another possible user friendly feature is "named" ACLs. One implementation of this
feature uses a named ACL as a template. If a user often sets ACLs to the same list of
36
Users, the setting user may want to create a named ACL as a template which, when
used, copies that list into the ACL. When the named ACL is changed, there is no
effect on the ACLs already in existence. This use of named ACLs has no particular
detriments and is of limited usefulness. The other implementation of named ACLs
places a pointer in the real ACL to the named ACL. Now when the named ACL gets
changed, all of the real ACLs that use it also get changed. This is very convenient for
the user, but when a named ACL is changed the user has no way of determining all of
the protected objects affected by the change. The named ACLs also have to be
protected in the same way as the real ACLs. Most of the features of named ACLs can
be replaced by some group and default mechanisms.
In summary, access control lists are the most desirable implementation of

discretionary access control. ACLs conveniently lend themselves to specifying a list
of named users who are allowed to access each object. Also, providing access to
defined groups of users is easily done with ACL-based mechanisms.
PROTECTION BITS
Protection bits are an incomplete attempt to represent the access control matrix by
column. Implementation of protection bits includes systems such as UNIX which use
protection bits associated with objects instead of a list of users who may access an
object. In the UNIX case the protection bits indicate whether everyone, the object's
group or only the owner has any of the access modes to the protected object. The user
who created the object is the owner, and that can only be changed through superuser
privileges. The owner is the only one (besides a superuser) who can change protection
bits.
The problem with protection bits is that they are an incomplete implementation of the
access control matrix model. The system cannot conveniently allow or disallow
access to a protected object on any single user basis. It has been suggested that groups
be set up so that any needed combination of users can be specified. But, for more than
a few users, the combinatory of such a solution are unrealistic. Also, groups are
controlled by the system administrator, and such a scheme would require full-time
attention.
PASSWORD DAC MECHANISMS
37
Password protection of objects attempts to represent the access control matrix by row.
If each user possessed his own password to each object, then the password is a ticket
to the object, similar to a capability system (except, of course, with no dynamic
domains). In most implementations of password protection, only one password per
object or one password per object per access mode exists. Passwords on protected
objects have been used in IBM's MVS and with other mechanisms in CDC's NOS to
implement DAC.
Many problems are associated with using a password protected DAC system. The use
of passwords prevents the TCB from controlling distribution of access permissions.
The sharing of passwords takes place outside the system. For a user to remember a
password for each protected object is virtually impossible and if the passwords are
stored in programs they are vulnerable. To restrict access to certain access modes
requires a password for each combination of access modes, but in most systems that
use passwords, access to a protected object is all or none. In such implementations,
revoking a user's access requires revoking access from all other users with similar
access and then distributing a new password to those who are to retain access. This
becomes almost impossible when passwords are stored in programs. To be secure,
passwords should be changed periodically, which is very difficult to do in such
password protected DAC systems.
In systems such as MVS the default access to a file is unrestricted access. A file is
protected only when the password protection is initiated for that file. Thus a new file
in MVS is not protected until the password protection mechanism is invoked. If
passwords are used as in the CDC NOS system to supplement another DAC
mechanism, they do have one positive aspect. If all objects are protected with
different passwords, Trojan horses can be restricted to only the objects that are handed
to them. The use of passwords for a complete DAC is strongly discouraged, because
there is no way to determine who has access to an object, and because managing such
a system properly is very difficult.
2.4. MANDATORY ACCESS CONTROL
38
Mandatory access control (MAC) involves aspects that the user cannot control (or is
not usually allowed to control). An example is that of a hardware address that cannot
be changed by a user. Under MAC, objects are tagged with labels representing the
sensitivity of the information contained within. MAC restricts access to objects based
on their sensitivity. Subject needs formal clearance (authorization) to access objects.
As an example, on Trusted Solaris, MAC relies on sensitivity labels attached to

objects. The MAC policy compares a user's current sensitivity label to that of the
object being accessed. The user is denied access unless certain MAC checks are
passed. It's mandatory as the labeling of information happens automatically, and
ordinary users cannot change labels. In contrast, DAC uses file permissions and
optional access control lists (ACLs) to restrict information based on the user's ID (uid)
or his group ID (gid). It's discretionary as a file's owner can change its permissions at
his discretion.
2.5. WINDOWS 2000 AUTHENTICATION
Authentication is performed by the system to be sure the user is really who they claim
to be. Authentication may be done at and for a local computer or at a global level for a
domain using domain controllers across the network.
Authentication uses X.509 standard and Kerberos.
Process of Logging On
1. CTRL+ALT+DEL is pressed, name and password entered, and local or

domain logon is indicated.
2. If the logon is local, the name and password are checked against the local
database. If the logon is a domain logon, the name and password are encrypted
into a key, and timestamp information is encrypted. This information is sent to
the Windows 2000 domain controller with an authentication request.
3. The domain controller decrypts the information and checks for a valid
timestamp. If the timestamp is valid, two Kerberos tickets are made and
encrypted with the password. The tickets are sent back to the client computer.
The tickets are:
o User session key - Used to log on.
39
o User ticket - Used to get other Kerberos tickets for accessing other
domain resources.
4. The client decrypts the tickets and uses the session key to log on.
Authentication when Accessing an Object
1. The user tries to access the network object.

2. The user ticket, user name, name of the object to access, and timestamp, are
sent with a Kerberos ticket granting service request to the domain controller.
3. The domain controller decrypts the information, checks the timestamp, makes
an encrypted session key (with user account and group information) and
returns the key to the local client.
4. The client sends a request for the resource with the session key to the server
that has the resource.
5. The receiving server decrypts the session key, and checks the information
against its ACL for the object being requested.
2.6. UNIX AUTHENTICATION
In the UNIX operating system environment, files and directories are organized in a
tree structure with specific access modes. The setting of these modes, through
permission bits (as octal digits), is the basis of UNIX system security. Permission bits
determine how users can access files and the type of access they are allowed. There
are three user access modes for all UNIX system files and directories: the owner, the
group, and others. Access to read, write and execute within each of the user types is
also controlled by permission bits.
Permission modes
40
OWNER GROUP OTHERS
------------------------------------------------------------------
rwx : rwx : rwx
-------------------------------------------------------------------
r = read
w = write
x = execute
-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file
drwx------ 2 sam A1 2 May 01 12:01 directory
Each file (and directory) has associated access rights, which may be found
by typing ls -l. Also, ls -lg gives additional information as to which group
owns the file (beng95 in the following example):
-rwxrw-r-- 1 ee51ab beng95 2450 Sept29 11:52 file1
In the left-hand column is a 10 symbol string consisting of the symbols d, r, w, x, -,

and, occasionally, s or S. If d is present, it will be at the left hand end of the string,
and indicates a directory: otherwise - will be the starting symbol of the string.
41
The 9 remaining symbols indicate the permissions, or access rights, and are taken as
three groups of 3.
• The left group of 3 gives the file permissions for the user that owns the file (or
directory) (ee51ab in the above example);
• The middle group gives the permissions for the group of people to whom the
file (or directory) belongs (eebeng95 in the above example);
• The rightmost group gives the permissions for all others.
The symbols r, w, etc., have slightly different meanings depending on whether

they refer to a simple file or to a directory.
Access rights on files.
• r (or -), indicates read permission (or otherwise), that is, the presence or
absence of permission to read and copy the file
• w (or -), indicates write permission (or otherwise), that is, the permission (or
otherwise) to change a file
• x (or -), indicates execution permission (or otherwise), that is, the permission
to execute a file, where appropriate
Access rights on directories.
• r allows users to list files in the directory;

• w means that users may delete files from the directory or move files into it;
• x means the right to access files in the directory. This implies that you may
read files in the directory provided you have read permission on the individual
files.
So, in order to read a file, you must have executed permission on the directory
containing that file, and hence on any directory containing those directories as a
subdirectory, and so on, up the tree.
Some examples
42
-rwxrwxrwx a file that everyone can read, write and execute (and delete).
a file that only the owner can read and write - no-one else
-rw------- can read or write and no-one has execution rights (e.g. your
mailbox file).
Chmod (changing a file mode)
Only the owner of a file can use chmod to change the permissions of a file. The
options of chmod are as follows
Symbol Meaning
u user
g group
o other
a all
r read
w write (and delete)
x execute (and access directory)
+ add permission
- take away permission
For example, to remove read write and execute permissions on the file biglist for
the group and others, type
% chmod go-rwx biglist
This will leave the other permissions unaffected.
To give read and write permissions on the file biglist to all,
% chmod a+rw biglist
43
Unit 3
3.1 CRYPTOGRAPHY INTRODUCTION
Definitions
Plaintext "The original message before it is encoded."

Encoding/Encryption "The process of disguising the plaintext."
Ciphertext "The enciphered version of the plaintext."
Decoding/Decryption "The process of reverting the cipher text back to the plain
text."
Cryptography "The science of keeping messages secret and of ensuring
authentication."
Cryptanalysis "The science (and art) of deciphering encoded messages
without the knowledge of the used key."
Cryptology Greek: kryptós = hidden, lógos=science. "The combination of
44
cryptography and cryptanalysis "The science of hidden,

disguised information."
3.2 TYPES OF CRYPTOGRAPHY
3.2.1 Conventional Encryption/Private-key Cryptography
In a "One-Key-Encryption" or "Conventional Encryption", the sender and the

recipient share the same key as their common secret
(source: www.PGPi.com):
At some earlier point in time the two correspondents, the sender and the recipient,
must have agreed on that key. If they are in different locations, they must trust a
courier or a phone system to transmit the secret key in a secure manner. Surely, this is
not very practical, particularly when many (new) parties are involved.
However, the major problem is the total number of keys involved. 2 correspondents
use 1 key, 3 use 3 keys, 4 use 6 keys, 5 use 10 keys, 100 use 4950 keys, 1000 use
499500 keys, etc. And each key must be stored in a secure manner. Key management
is enough of a difficult task that a name was invented for it: The Key Distribution
Problem. It is the reason why One-Key-Cryptography is not appropriate for today's
secure electronic data transfers between many parties involved.
Every Cipher is made up of two ingredients: an encryption method (the "algorithm")

and the set of all possible keys (the "key space"). The sender may now choose from
the number of possible keys to encode his secret message. The security of the
45
cryptosystem shall not be based on keeping the algorithm secret, but solely keeping
the key secret.
Private Key Cryptography means that the knowledge of the encoding key yields the
decoding key. Such Ciphers are therefore also called "Symmetric Ciphers". If a
Cipher only offers a small number of keys (i.e. the Caesar Cipher) it can be broken by
simply testing the possible keys. A huge number of keys assures the security of a
cipher
Private Key Cryptography provides "high-security" ciphers, however, their usage is
not practical because of the key distribution problem. It describes the difficulty of
exchanging and handling a large number of keys. I.e. 1000 correspondents have to
handle a total of 499500 keys. The number of keys increases with the square of the
number of correspondents.
3.2.2 Two-key/Public-key Cryptography
The "Two-Key Cryptography" or "Public-Key Cryptography" was a major

breakthrough in 1976. It makes the inconceivable reality: A Public Key is used to
encode the plain text, its corresponding Private Key is used to decode the cipher text.
The clue: Although the encoding key available to the whole world, nobody is capable
of figuring out the decoding key. The figure below shows the how "Two-Key
Cryptography" is performed.
(source: www.PGPi.com):
The primary benefit of public key cryptography is that it allows people who have no
preexisting security arrangement to exchange messages securely. The need for sender
and receiver to share secret keys via some secure channel is eliminated; all
46
communications involve only public keys, and no private key is ever transmitted or
shared.
3.2.3 Transposition and Substitution Ciphers
Substitution and Transposition Ciphers are two categories of ciphers used in classical
cryptography. Substitution and Transposition differ in how chunks of the message are
handled by the encryption process. Substitution ciphers encrypt plaintext by changing
the plaintext one piece at a time.
The Ceasar Cipher was an early substitution cipher. In the Caesar Cipher, each
character is shifted three places up. Therefore, A becomes D and B becomes E, etc...
This table shows "VOYAGER" being encrypted with the Caesar substution cipher:
Plaintext V O Y A G E R
Key +3 +3 +3 +3 +3 +3 +3
Ciphertext Y R B D J H U
Transposition ciphers encrypt plaintext by moving small pieces of the message
around.
This table shows "VOYAGER" being encrypted with a primitive transposition cipher
where every two letters are switched with each other:
V OYAGE R
O VAYE GR
3.2.4 Stream and Block Ciphers
Block and Stream Ciphers are two categories of ciphers used in classical
cryptography. Block and Stream Ciphers differ in how large a piece of the message is
processed in each encryption operation. Block ciphers encrypt plaintext in chunks.
Common block sizes are 64 and 128 bits. Stream ciphers encrypt plaintext one byte or
one bit at a time. A stream cipher can be thought of as a block cipher with a really
small block size. Generally speaking, block ciphers are more efficient for computers
and stream ciphers are easier for humans to do by hand.
3.3 CAESAR SUBSTITUTION
The simplest of all substitution ciphers is the one in which the cipher letters results
from shifting plain letters by the same distance. Among those, the best known is
47
called "Caesar Cipher", used by Julius Caesar, in which each A is encrypted as D, B

as E, C as F,... etc. Here key is 3
Mathematically, the encryption and decryption functions can be described as follows:
The sender encodes each plain text letter P using the key b as follows:
C= (P+b) mod 26
The recipient decodes each cipher text letter C using the key b as follows:
P=(C-b) mod 26
3.4 PLAYFAIR CIPHER
The best known substitution cipher that encrypts pairs of letters is the Playfair Cipher
invented by Sir Charles Wheatstone but championed at the British Foreign Office by
Lyon Playfair, the first Baron Playfair of St. Andrews, whose name the cipher bears.
Here, a 5 x 5-square matrix containing the 26 letters of the alphabet (I and J are
treated as the same letter) is used to carry out the encryption. A key word,
MONARCHY in this example, is filled in first, and the remaining unused letters of
the alphabet are entered in their lexicographic order.
Pairs of plaintext letters are encrypted with the matrix by first locating the two
plaintext letters in the matrix. They are
(1) in different rows and columns or
(2) in the same row or
(3) in the same column or
(4) alike.
The corresponding encryption (replacement) rules are the following:

1. If the pair of letters are in different rows and columns, each letter is replaced by the
48
letter that is in the same row but in the other column; i.e., to encrypt WE, W is
replaced by U and E by G.
2. If two letters are in the same row simply shift both one position to the right. I.e. A
and R are in the same row. A is encrypted as R and R (reading the row cyclically) as
M.
3. Similarly, if two letters are in the same column shift both one position down. I.e. I
and S are in the same column. I is encrypted as S and S as X.
4. If a double letter occurs, a spurious symbol, say Q, is introduced so that the MM in

SUMMER would encrypt into NL for MQ and CL for ME.
5. An X is appended to the end of the plaintext if necessary to cause the plaintext to

have an even number of letters.
3.5 MONOALPHABETIC SUBSTITUTION
The Caesar Cipher, the Multiplication Cipher and the Linear Cipher have one
property in common. They all fall in the category of Monoalphabetic Ciphers: "Same
plain letters are encoded to the same cipher letter." i.e. in the Caesar Cipher each "a"
turned into "d", each "b" turned into "e", etc.
The reason why such Ciphers can be broken is the following: Although letters are
changed the underlying letter frequencies are not! If the plain letter "a" occurs 10
times its cipher letter will do so 10 times. Therefore, any monoalphabetic Cipher can
be broken with the aid of letter frequency analysis.
3.6 POLYALPHABETIC SUBSTITUTION
Polyalphabetic substitution cipher is simply a substitution cipher with an alphabet that

changes. For example one could have two alphabets:
Plain Alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Cipher Alphabet #1: B D F H J L N P R T V X Z A C E G I K M O Q S U W Y
Cipher Alphabet #2: Z Y X W V U T S R Q P O N M L K J I H G F E D C B A
Now to encrypt the message ``The quick brown fox jumped over the lazy dog" we
would alternate between the two cipher alphabets, using #1 for every first letter and
#2 for every second, to get: ``Msj joxfp dicda ucu tfzkjw ceji msj xzyb hln".
Polyalphabetic substitution ciphers are useful because they cannot be broken using
49
frequency analysis.The number of letters encrypted before a polyalphabetic

substitution cipher returns to its first cipher alphabet is called its period. The larger the
period, the stronger the cipher.
Vigenere Cipher
The polyalphabetic substitution cipher involves the use of two or more cipher
alphabets. Instead of there being a one-to-one relationship between each letter and its
substitute, there is a one-to-many relationship between each letter and its substitutes.
The Vigenere Cipher , proposed by Blaise de Vigenere is a polyalphabetic

substitution based on the following tableau:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
A ABCDEFGHIJKLMNOPQRSTUVWXYZ
B BCDEFGHIJKLMNOPQRSTUVWXYZA
C CDEFGHIJKLMNOPQRSTUVWXYZAB
D DEFGHIJKLMNOPQRSTUVWXYZABC
E EFGHIJKLMNOPQRSTUVWXYZABCD
F FGHIJKLMNOPQRSTUVWXYZABCDE
G GHIJKLMNOPQRSTUVWXYZABCDEF
H HIJKLMNOPQRSTUVWXYZABCDEFG
I IJKLMNOPQRSTUVWXYZABCDEFGH
J JKLMNOPQRSTUVWXYZABCDEFGHI
K KLMNOPQRSTUVWXYZABCDEFGHIJ
L LMNOPQRSTUVWXYZABCDEFGHIJK
M MNOPQRSTUVWXYZABCDEFGHIJKL
N NOPQRSTUVWXYZABCDEFGHIJKLM
O OPQRSTUVWXYZABCDEFGHIJKLMN
P PQRSTUVWXYZABCDEFGHIJKLMNO
Q QRSTUVWXYZABCDEFGHIJKLMNOP
R RSTUVWXYZABCDEFGHIJKLMNOPQ
S STUVWXYZABCDEFGHIJKLMNOPQR
T TUVWXYZABCDEFGHIJKLMNOPQRS
U UVWXYZABCDEFGHIJKLMNOPQRST
50
V VWXYZABCDEFGHIJKLMNOPQRSTU
W WXYZABCDEFGHIJKLMNOPQRSTUV
X XYZABCDEFGHIJKLMNOPQRSTUVW
Y YZABCDEFGHIJKLMNOPQRSTUVWX
Z ZABCDEFGHIJKLMNOPQRSTUVWXY
Note that each row of the table corresponds to a Caesar Cipher. The first row is a shift
of 0; the second is a shift of 1; and the last is a shift of 25.
The Vigenere cipher uses this table together with a keyword to encipher a message.
For example, enciphering the plaintext message:
TO BE OR NOT TO BE THAT IS THE QUESTION

using the keyword RELATIONS. We begin by writing the keyword, repeated as many
times as necessary, above the plaintext message. To derive the ciphertext using the
tableau, for each letter in the plaintext, one finds the intersection of the row given by
the corresponding keyword letter and the column given by the plaintext letter itself to
pick out the ciphertext letter.
Keyword: RELAT IONSR ELATI ONSRE LATIO NSREL
Plaintext: TOBEO RNOTT OBETH ATIST HEQUE STION
Ciphertext: KSMEH ZBBLK SMEMP OGAJX SEJCS FLZSY
Decipherment of an encrypted message is equally straightforward. One writes the
keyword repeatedly above the message:
Keyword: RELAT IONSR ELATI ONSRE LATIO NSREL
Ciphertext: KSMEH ZBBLK SMEMP OGAJX SEJCS FLZSY
Plaintext: TOBEO RNOTT OBETH ATIST HEQUE STION
This time one uses the keyword letter to pick a column of the table and then traces
down the column to the row containing the ciphertext letter. The index of that row is
the plaintext letter.
The strength of the Vigenere cipher against frequency analysis can be seen by
examining the above ciphertext. Note that there are 7 'T's in the plaintext message and
that they have been encrypted by 'H,' 'L,' 'K,' 'M,' 'G,' 'X,' and 'L' respectively. This
successfully masks the frequency characteristics of the English 'T.' One way of
looking at this is to notice that each letter of our keyword RELATIONS picks out 1 of
the 26 possible substitution alphabets given in the Vigenere tableau. Thus, any
51
message encrypted by a Vigenere cipher is a collection of as many simple substitution

ciphers as there are letters in the keyword.
3.7 CRYPTANALYSIS
Cryptanalysis (from the Greek kryptós, "hidden", and analýein, "to loosen" or "to
untie") is the study of methods for obtaining the meaning of encrypted information,
without access to the secret information which is normally required to do so.
Typically, this involves finding the secret key. In non-technical language, this is the
practice of code breaking or cracking the code, although these phrases also have a
specialized technical meaning
Types of Cryptanalytic attacks
1 Brute force Attacks: It is a method of defeating a cryptographic scheme by

trying a large number of possibilities; for example, exhaustively working
through all possible keys in order to decrypt a message. In most schemes, the
theoretical possibility of a brute force attack is recognized, but it is set up in
such a way that it would be computationally infeasible to carry out.
2 Ciphertext-only: the cryptanalyst has access only to a collection of

ciphertexts or codetexts.
3 Known-plaintext: the attacker has a set of ciphertexts to which he knows the

corresponding plaintext.
4 Chosen-plaintext (chosen-ciphertext): the attacker can obtain the ciphertexts

(plaintexts) corresponding to an arbitrary set of plaintexts (ciphertexts) of his
own choosing.
5 Adaptive chosen-plaintext: like a chosen-plaintext attack, except the attacker

can choose subsequent plaintexts based on information learned from previous
encryptions. Similarly Adaptive chosen ciphertext attack.
6 Related-key attack: Like a chosen-plaintext attack, except the attacker can

obtain ciphertexts encrypted under two different keys. The keys are unknown,
but the relationship between them is known; for example, two keys that differ
in the one bit.
3.8. FIESTEL NETWORKS
52
In cryptography, a Feistel cipher is a block cipher with a particular structure, named

after IBM cryptographer Horst Feistel; it is also commonly known as a Feistel
network. A large proportion of block ciphers use the scheme, including the Data
Encryption Standard(DES). The Feistel structure has the advantage that encryption
and decryption operations are very similar, even identical in some cases, requiring
only a reversal of the key schedule. Therefore the size of the code or circuitry required
to implement such a cipher is nearly halved.
Feistel networks and similar constructions are product ciphers, and so combine
multiple rounds of repeated operations, such as:
 Bit-shuffling (often called permutation boxes or P-boxes)
 Simple non-linear functions (often called substitution boxes or S-boxes)
 Linear mixing (in the sense of modular algebra) using XOR
to produce a function with large amounts of what Claude Shannon described as

"confusion and diffusion". Bit shuffling creates the diffusion effect, while substitution
is used for confusion. In Shannon's original definitions, confusion refers to making the
relationship between the key and the ciphertext as complex and involved as possible;
diffusion refers to the property that redundancy in the statistics of the plaintext is
"dissipated" in the statistics of the ciphertext.
The basic operation is as follows:
Split the plaintext block into two equal pieces, (L0, R0)
For each round , compute
L i = Ri − 1
where f is the round function and Ki is the sub-key.
Then the ciphertext is (Ln, Rn).
Regardless of the function f, decryption is accomplished via
R i − 1 = Li
One advantage of this model is that the function used does not have to be invertible,
and can be very complex. This diagram illustrates both encryption and decryption.
53
Note the reversal of the subkey order for decryption; this is the only difference
between encryption and decryption:
3.9 DATA ENCRYPTION STANDARD
DES encrypts and decrypts data in 64-bit blocks, using a 64-bit key (although the
effective key strength is only 56 bits, as explained below). It takes a 64-bit block of
plaintext as input and outputs a 64-bit block of ciphertext. Since it always operates on
blocks of equal size and it uses both permutations and substitutions in the algorithm,
DES is both a block cipher and a product cipher.
DES has 16 rounds, meaning the main algorithm is repeated 16 times to produce the
ciphertext. It has been found that the number of rounds is exponentially proportional
to the amount of time required to find a key using a brute-force attack. So as the
number of rounds increases, the security of the algorithm increases exponentially.
54
The block diagram of DES is depicted below.
3.9.1 Key Scheduling
Although the input key for DES is 64 bits long, the actual key used by DES is only 56
bits in length. The bits at positions of multiples of eight are ignored, thus resulting in
a key length of 56 bits.
The first step is to pass the 64-bit key through a permutation called Permuted Choice
1, or PC-1 for short. The table for this is given below. Note that in all subsequent
descriptions of bit numbers, 1 is the left-most bit in the number, and n is the rightmost
bit.
55
PC-1: Permuted Choice 1

Bit 0 1 2 3 4 5 6
1 57 49 41 33 25 17 9
8 1 58 50 42 34 26 18
15 10 2 59 51 43 35 27
22 19 11 3 60 52 44 36
29 63 55 47 39 31 23 15
36 7 62 54 46 38 30 22
43 14 6 61 53 45 37 29
50 21 13 5 28 20 12 4
Now that we have the 56-bit key, the next step is to use this key to generate 16 48-bit
subkeys, called K[1]-K[16], which are used in the 16 rounds of DES for encryption
and decryption. The procedure for generating the subkeys - known as key scheduling -
is fairly simple:
1. Set the round number R to 1.
2. Split the current 56-bit key, K, up into two 28-bit blocks, L (the left-hand half) and
R (the right-hand half).
3. Rotate L left by the number of bits specified in the table below, and rotate R left by
the same number of bits as well.
4. Join L and R together to get the new K.
5. Apply Permuted Choice 2 (PC-2) to K to get the final K[R], where R is the round
number we are on.
6. Increment R by 1 and repeat the procedure until we have all 16 subkeys K[1]-
K[16].
Here are the tables involved in these operations:
Subkey Rotation Table

Round Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Number of bits to 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1
56
rotate
PC-2: Permuted Choice 2
Bit 0 1 2 3 4 5
1 14 17 11 24 1 5
7 3 28 15 6 21 10
13 23 19 12 4 26 8
19 16 7 27 20 13 2
25 41 52 31 37 47 55
31 30 40 51 45 33 48
37 44 49 39 56 34 53
43 46 42 50 36 29 32
3.9.2 Plaintext Preparation
Once the key scheduling has been performed, the next step is to prepare the plaintext
for the actual encryption. This is done by passing the plaintext through a permutation
called the Initial Permutation, or IP for short. This table also has an inverse, called the
Inverse Initial Permutation, or IP^(-1). Sometimes IP^(-1) is also called the Final
Permutation. Both of these tables are shown below.
IP: Initial Permutation

Bit 0 1 2 3 4 5 6 7
1 58 50 42 34 26 18 10 2
9 60 52 44 36 28 20 12 4
17 62 54 46 38 30 22 14 6
25 64 56 48 40 32 24 16 8
33 57 49 41 33 25 17 9 1
41 59 51 43 35 27 19 11 3
49 61 53 45 37 29 21 13 5
57 63 55 47 39 31 23 15 7
IP^(-1): Inverse Initial Permutation

Bit 0 1 2 3 4 5 6 7
1 40 8 48 16 56 24 64 32
9 39 7 47 15 55 23 63 31
17 38 6 46 14 54 22 62 30
25 37 5 45 13 53 21 61 29
33 36 4 44 12 52 20 60 28
41 35 3 43 11 51 19 59 27
49 34 2 42 10 50 18 58 26
57 33 1 41 9 49 17 57 25
These tables are used just like PC-1 and PC-2 were for the key scheduling. By looking
at the table is becomes apparent why one permutation is called the inverse of the
other. For example, let's examine how bit 32 is transformed under IP. In the table, bit
32 is located at the intersection of the column labeled 4 and the row labeled 25. So
57
this bit becomes bit 29 of the 64-bit block after the permutation. Now let's apply IP^(-
1). In IP^(-1), bit 29 is located at the intersection of the column labeled 7 and the row
labeled 25. So this bit becomes bit 32 after the permutation. And this is the bit
position that we started with before the first permutation. So IP^(-1) really is the
inverse of IP. It does the exact opposite of IP. If you run a block of plaintext through
IP and then pass the resulting block through IP^(-1), you'll end up with the original
block.
3.9.3 DES Core Function
Once the key scheduling and plaintext preparation have been completed, the actual
encryption or decryption is performed by the main DES algorithm. The 64-bit block
of input data is first split into two halves, L and R. L is the left-most 32 bits, and R is
the right-most 32 bits. The following process is repeated 16 times, making up the 16
rounds of standard DES. We call the 16 sets of halves L[0]-L[15] and R[0]-R[15].
1. R[I-1] - where I is the round number, starting at 1 - is taken and fed into the E-Bit
Selection Table, which is like a permutation, except that some of the bits are used
more than once. This expands the number R[I-1] from 32 to 48 bits to prepare for the
next step.
2. The 48-bit R[I-1] is XORed with K[I] and stored in a temporary buffer so that R[I-
1] is not modified.
3. The result from the previous step is now split into 8 segments of 6 bits each. The
left-most 6 bits are B[1], and the right-most 6 bits are B[8]. These blocks form the
index into the S-boxes, which are used in the next step. The Substitution boxes,
known as S-boxes, are a set of 8 two-dimensional arrays, each with 4 rows and 16
columns. The numbers in the boxes are always 4 bits in length, so their values range
from 0-15. The S-boxes are numbered S[1]-S[8].
4. Starting with B[1], the first and last bits of the 6-bit block are taken and used as an
index into the row number of S[1], which can range from 0 to 3, and the middle four
bits are used as an index into the column number, which can range from 0 to 15. The
number from this position in the S-box is retrieved and stored away. This is repeated
with B[2] and S[2], B[3] and S[3], and the others up to B[8] and S[8]. At this point,
we now have 8 4-bit numbers, which when strung together one after the other in the
order of retrieval, give a 32-bit result.
58
5. The result from the previous stage is now passed into the P Permutation.
6. This number is now XORed with L[I-1], and moved into R[I]. R[I-1] is moved into
L[I].
7. At this point we have a new L[I] and R[I]. Here, we increment I and repeat the core
function until I = 17, which means that 16 rounds have been executed and keys K[1]-
K[16] have all been used.
When L[16] and R[16] have been obtained, they are joined back together in the same
fashion they were split apart (L[16] is the left-hand half, R[16] is the right-hand half),
then the two halves are swapped, R[16] becomes the left-most 32 bits and L[16]
becomes the right-most 32 bits of the pre-output block and the resultant 64-bit number
is called the pre-output.
Tables used in the DES Core Function
E-Bit Selection Table

Bit 0 1 2 3 4 5
1 32 1 2 3 4 5
7 4 5 6 7 8 9
13 8 9 10 11 12 13
19 12 13 14 15 16 17
25 16 17 18 19 20 21
31 20 21 22 23 24 25
37 24 25 26 27 28 29
43 28 29 30 31 32 1
P Permutation
Bit 0 1 2 3
1 16 7 20 21
5 29 12 28 17
9 1 15 23 26
13 5 18 31 10
17 2 8 24 14
21 32 27 3 9
25 19 13 30 6
29 22 11 4 25
59
S-Box 1: Substitution Box 1

Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13

Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
1 3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
2 0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
3 13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
1 13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
2 13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
3 1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
Row / Column 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
1 13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
2 10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
3 3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
1 14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
2 4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
3 11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
1 10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
2 9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
3 4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
60
Column
0 4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
1 13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
2 1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
3 6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Column
0 13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
1 1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
2 7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
3 2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
3.9.4 How to use the S-Boxes
The purpose of this example is to clarify how the S-boxes work. Suppose we have the
following 48-bit binary number:
011101000101110101000111101000011100101101011101
In order to pass this through steps 3 and 4 of the Core Function as outlined above, the
number is split up into 8 6-bit blocks, labeled B[1] to B[8] from left to right:
011101 000101 110101 000111 101000 011100 101101 011101
Now, eight numbers are extracted from the S-boxes - one from each box:
B[1] = S[1](01, 1110) = S[1][1][14] = 3 = 0011

B[2] = S[2](01, 0010) = S[2][1][2 ] = 4 = 0100
B[3] = S[3](11, 1010) = S[3][3][10] = 14 = 1110
B[4] = S[4](01, 0011) = S[4][1][3 ] = 5 = 0101
B[5] = S[5](10, 0100) = S[5][2][4 ] = 10 = 1010
B[6] = S[6](00, 1110) = S[6][0][14] = 5 = 0101
B[7] = S[7](11, 0110) = S[7][3][6 ] = 10 = 1010
B[8] = S[8](01, 1110) = S[8][1][14] = 9 = 1001
In each case of S[n][row][column], the first and last bits of the current B[n] are used
as the row index, and the middle four bits as the column index.
The results are now joined together to form a 32-bit number which serves as the input
to stage 5 of the Core Function (the P Permutation):
00110100111001011010010110101001
61
3.9.5 Ciphertext Preparation
The final step is to apply the permutation IP^(-1) to the pre-output. The result is the
completely encrypted ciphertext.
3.9.6 Encryption and Decryption
The same algorithm can be used for encryption or decryption. The method described
above will encrypt a block of plaintext and return a block of ciphertext. In order to
decrypt the ciphertext and get the original plaintext again, the procedure is simply
repeated but the subkeys are applied in reverse order, from K[16]-K[1]. That is, stage
2 of the Core Function as outlined above changes from R[I-1] XOR K[I] to R[I-1]
XOR K[17-I]. Other than that, decryption is performed exactly the same as
encryption.
3.9.7 Strength of DES
1 With a key length of 56 bits, a brute force attack becomes impractical

2 Design algorithm of S-boxes is kept a secret
3 DES is also resistant to timing attacks
3.10 COMPARISON OF MODERN SYMMETRIC KEY ALGORITHMS
Algorithm Plaintext Ciphertext Key size Rounds Advantages

DES 64 bits 64 bits 56 bits 16 Simple and fast
Less mathematical
calculations
Cryptanalysis is
difficult
3DES 64 bits 64 bits 168 bits 48 DES More reliable
rounds Easy to upgrade the
software to 3DES
Longer keylength,
difficult to crytanalyse
AES 128 bits 128 bits 128/192/ 10/12/14 Longer keylengths
256 bits resp. supported
62
More flexible
Blowfish 64 bits 64 bits 32-448 16 Fast and secure
bits Compact
RC5 32/64/128 32/64/128 0-2040 variable Simple and fast
bits bits bits Adaptable to
processors of different
word length
Data dependent
rotations
3.11 MODES OF OPERATION OF DES
3.11.1 ECB (Electronic Code Book)
This is the regular DES algorithm. Data is divided into 64-bit blocks and each
block is encrypted one at a time. Separate encryptions with different blocks
are totally independent of each other. This means that if data is transmitted
over a network or phone line, transmission errors will only affect the block
containing the error. It also means, however, that the blocks can be rearranged,
thus scrambling a file beyond recognition, and this action would go
undetected. ECB is the weakest of the various modes because no additional
security measures are implemented besides the basic DES algorithm.
However, ECB is the fastest and easiest to implement, making it the most
common mode of DES.
63
3.11.2 CBC (Cipher Block Chaining).
In this mode of operation, each block of ECB encrypted ciphertext is XORed

with the next plaintext block to be encrypted, thus making all the blocks
dependent on all the previous blocks. This means that in order to find the
plaintext of a particular block, you need to know the ciphertext, the key, and
the ciphertext for the previous block. The first block to be encrypted has no
previous ciphertext, so the plaintext is XORed with a 64-bit number called the
Initialization Vector, or IV for short. So if data is transmitted over a network
or phone line and there is a transmission error, the error will be carried
forward to all subsequent blocks since each block is dependent upon the last.
This mode of operation is more secure than ECB because the extra XOR step
adds one more layer to the encryption process.
64
3.11.3 CFB (Cipher Feed Back)

In this mode, blocks of plaintext that are less than 64 bits long can be
encrypted. Normally, special processing has to be used to handle files whose size
is not a perfect multiple of 8 bytes, but this mode removes that necessity (Stealth
handles this case by adding several dummy bytes to the end of a file before
encrypting it). The plaintext itself is not actually passed through the DES
algorithm, but merely XORed with an output block from it, in the following
manner: A 64-bit block called the Shift Register is used as the input plaintext to
DES. This is initially set to some arbitrary value, and encrypted with the DES
algorithm. The ciphertext is then passed through an extra component called the M-
box, which simply selects the left-most M bits of the ciphertext, where M is the
number of bits in the block we wish to encrypt. This value is XORed with the real
65
plaintext, and the output of that is the final ciphertext. Finally, the ciphertext is fed
back into the Shift Register, and used as the plaintext seed for the next block to be
encrypted. As with CBC mode, an error in one block affects all subsequent blocks
during data transmission. This mode of operation is similar to CBC and is very
secure, but it is slower than ECB due to the added complexity.
3.11.4 OFB (Output Feed Back)
This is similar to CFB mode, except that the ciphertext output of DES
is fed back into the Shift Register, rather than the actual final ciphertext. The
Shift Register is set to an arbitrary initial value, and passed through the DES
algorithm. The output from DES is passed through the M-box and then fed
back into the Shift Register to prepare for the next block. This value is then
XORed with the real plaintext (which may be less than 64 bits in length, like
66
CFB mode), and the result is the final ciphertext. Note that unlike CFB and
CBC, a transmission error in one block will not affect subsequent blocks
because once the recipient has the initial Shift Register value, it will continue
to generate new Shift Register plaintext inputs without any further data input.
However, this mode of operation is less secure than CFB mode because only
the real ciphertext and DES ciphertext output is needed to find the plaintext of
the most recent block. Knowledge of the key is not required.
67
3.11.5 CTR (Counter)
A counter, equal to the plaintext block size is used. The counter value must be
different for each plaintext block that is encrypted. The counter is initialized to some
value and then incremented by 1 for each substitution. For encryption, the counter is
encrypted and then XORed with the plaintext block to produce the ciphertext block.
3.12 PUBLIC KEY CRYPTOGRAPHY
68
3.12.1 Comparison of Symmetric Key and Public Key Cryptography
With symmetric-key encryption, the encryption key can be calculated from

the decryption key and vice versa. With most symmetric algorithms, the same key is
used for both encryption and decryption, as shown in Figure
Implementations of symmetric-key encryption can be highly efficient, so that users do

not experience any significant time delay as a result of the encryption and decryption.
Symmetric-key encryption is effective only if the symmetric key is kept secret by the
two parties involved. If anyone else discovers the key, it affects both confidentiality
and authentication. A person with an unauthorized symmetric key not only can
decrypt messages sent with that key, but can encrypt new messages and send them as
if they came from one of the two parties who were originally using the key.
Public-key encryption (also called asymmetric encryption) involves a pair of

keys--a public key and a private key--associated with an entity that needs to
authenticate its identity electronically or to sign or encrypt data. Each public key is
published, and the corresponding private key is kept secret. Data encrypted with the
public key can be decrypted only with the private key. The figure shows a simplified
view of the way public-key encryption works.
The scheme lets us freely distribute a public key, and only you will be able to read
data encrypted using this key. In general, to send encrypted data to someone, we
encrypt the data with that person's public key, and the person receiving the encrypted
data decrypts it with the corresponding private key. Compared with symmetric-key
69
encryption, public-key encryption requires more computation and is therefore not

always appropriate for large amounts of data. However, it's possible to use public-key
encryption to send a symmetric key, which can then be used to encrypt additional
data.
As it happens, the reverse of the scheme shown in Figure also works: data encrypted
with your private key can be decrypted only with your public key. This would not be
a desirable way to encrypt sensitive data, however, because it means that anyone with
your public key, which is by definition published, could decrypt the data.
Nevertheless, private-key encryption is useful, because it means you can use your
private key to sign data with your digital signature--an important requirement for
electronic commerce and other commercial applications of cryptography.
3.13 RSA ALGORITHM
The algorithm was described in 1977 by Ron Rivest, Adi Shamir and Len Adleman at
MIT; the letters RSA are the initials of their surnames. This is the most commonly
used algorithm in public key cryptography
3.13.1 Key Generation
Suppose a user X wishes to allow Y to send a private message over an insecure

transmission medium. X takes the following steps to generate a public key and a
private key:
1. Choose two large prime numbers and such that , randomly and
independently of each other.
2. Compute .
3. Compute the totient .
4. Choose an integer e such that which is coprime to .
5. Compute d such that
The public key consists of
 n, the modulus, and
70
 e, the public exponent (sometimes encryption exponent).
The private key consists of
 n, the modulus, which is public and appears in the public key, and
 d, the private exponent (sometimes decryption exponent), which must be kept

secret.
3.13.2 Encrypting messages
Suppose Bob wishes to send a message M to Alice. He turns M into a number m < n,
using some previously agreed-upon reversible protocol known as a padding scheme.
Bob now has m, and knows n and e, which Alice has announced. He then computes
the ciphertext c corresponding to m:
Bob then transmits c to Alice
3.13.3 Decrypting messages
Alice receives c from Bob, and knows her private key d. She can recover m from c by
the following procedure:
The proof is given in Appendix
3.13.4 A working example
Here is an example of RSA encryption and decryption. The parameters used here are
artificially smallWe let
p = 61 - first prime number (to be kept secret or deleted securely)

q = 53 - second prime number (to be kept secret or deleted securely)
n = pq = - modulus (to be made public)
3233
e = 17 - public exponent (to be made public)
d = 2753 - private exponent (to be kept secret)
The public key is (e, n). The private key is d. The encryption function is:
71
encrypt(m) = me mod n = m17 mod 3233
where m is the plaintext. The decryption function is:
decrypt(c) = cd mod n = c2753 mod 3233
where c is the ciphertext.
To encrypt the plaintext value 123, we calculate
encrypt(123) = 12317 mod 3233 = 855
To decrypt the ciphertext value 855, we calculate
decrypt(855) = 8552753 mod 3233 = 123
3.13.5 Security of RSA
The security of the RSA cryptosystem is based on two mathematical problems: the
problem of factoring very large numbers, and the RSA problem. Full decryption of an
RSA ciphertext is thought to be infeasible on the assumption that both of these
problems are hard, i.e., no efficient algorithm exists for solving them.
The RSA problem is defined as the task of taking eth roots modulo a composite n:
recovering a value m such that me=c mod n, where (e, n) is an RSA public key and c
is an RSA ciphertext. Currently the most promising approach to solving the RSA
problem is to factor the modulus n. With the ability to recover prime factors, an
attacker can compute the secret exponent d from a public key (e, n), then decrypt c
using the standard procedure. To accomplish this, an attacker factors n into p and q,
and computes (p-1)(q-1) which allows the determination of d from e. No polynomial-
time method for factoring large integers on a classical computer has yet been found,
but it has not been proven that none exists.
3.13.6 Practical Considerations
Speed
RSA is much slower than DES and other symmetric cryptosystems.
Key distribution
72
As with all ciphers, how RSA public keys are distributed is important to security. Key
distribution must be secured against a man-in-the-middle attack. In principle, neither
sender nor receiver would be able to detect an outsider’s presence. Defenses against
such attacks are often based on digital certificates.
Timing attacks
3.13.7 Comparison of RSA and DES
Feature DES RSA

speed high low
data block length 64 bits minimum 512 bits
key length 56 bits minimum 512 bits
use of data space full, 64 bits (264), 8 variable, limited, not
bytes defined,
ciphering & deciphering same different
key
ciphering & deciphering different same
algorithm
algorithm contains only no no
XOR and branching
cryptanalysis method differential method product factorization
3.14 DIFFIE HELLMAN KEY EXCHANGE
Diffie-Hellman key agreement was invented in 1976 during a collaboration between

Whitfield Diffie and Martin Hellman and was the first practical method for
establishing a shared secret over an unprotected communications channel.
3.14.1 Description
73
The simplest, and original, implementation of the protocol uses the multiplicative
group of integers modulo p, where p is prime and g is primitive mod p. Modulo (or
mod) simply means that the integers between 1 and p − 1 are used with normal
multiplication, exponentiation and division, except that after each operation the result
keeps only the remainder after dividing by p. Here is an example of the protocol:
1. Alice and Bob agree to use a prime number p=23 and base g=5.
2. Alice chooses a secret integer a=6, then sends Bob (ga mod p)
o 56 mod 23 = 8.
3. Bob chooses a secret integer b=15, then sends Alice (gb mod p)
o 515 mod 23 = 19.
4. Alice computes (gb mod p)a mod p
o 196 mod 23 = 2.
5. Bob computes (ga mod p)b mod p
815 mod 23 = 2.
Both Alice and Bob have arrived at the same value, because gab and gba are equal. Note
that only a, b, gab and gba are kept secret. All the other values are sent in the
clear. Once Alice and Bob compute the shared secret they can use it as an
encryption key, known only to them, for sending messages across the same
open communications channel. Of course, much larger values of a,b, and p
would be needed to make this example secure, since it is easy to try all the
possible values of gab mod 23 (there will be, at most, 22 such values, even if a
and b are large). If p was a prime of more than 300 digits, and a and b were at
least 100 digits long, then even the best known algorithms for finding a given
only g, p, and ga mod p (known as the discrete logarithm problem) would take
longer than the lifetime of the universe to run. g need not be large at all, and in
practice is usually either 2 or 5.
Here's a more general description of the protocol:
74
1. Alice and Bob agree on a finite cyclic group G and a generating element g in
G. (This is usually done long before the rest of the protocol; g is assumed to be
known by all attackers.) We will write the group G multiplicatively.
2. Alice picks a random natural number a and sends ga to Bob.
3. Bob picks a random natural number b and sends gb to Alice.
4. Alice computes (gb)a.
5. Bob computes (ga)b. Both Alice and Bob are now in possession of the group
element gab which can serve as the shared secret key.
3.14.2 Security
The protocol is considered secure against eavesdroppers if G and g are chosen

properly. The eavesdropper must solve the Diffie-Hellman problem to obtain
gab. This is currently considered difficult. An efficient algorithm to solve the
discrete logarithm problem would make it easy to compute a or b and solve the
Diffie-Hellman problem, making this protocol insecure.
The order of G should be prime or have a large prime factor to prevent obtaining a or
b. The secret integers a and b are discarded at the end of the session.
Therefore, Diffie-Hellman key exchange by itself trivially achieves perfect
forward secrecy because no long-term private keying material exists to be
disclosed.
3.14.3 Authentication
In the original description, the Diffie-Hellman exchange by itself does not provide
authentication of the parties, and is thus vulnerable to man in the middle
attack. The man-in-the-middle may establish two distinct Diffie-Hellman keys,
one with Alice and the other with Bob, and then try to masquerade as Alice to
Bob and/or vice-versa, perhaps by decrypting and re-encrypting messages
passed between them. Some method to authenticate these parties to each other
is generally needed
75
3.15. MESSAGE AUTHENTICATION CODE (MAC) AND HASH FUNCTIONS
Message authentication is concerned with
a) Protecting integrity of the message
b) Validating identity of the originator
c) Non-repudiation of origin
There are three different ways to achieve message authentication
Message Encryption
MAC
Hash functions
Message encryption can be either a symmetric key encryption or public key

encryption. If symmetric key encryption is used receiver and sender should
communicate the secret key, which is a hazardous task. If public key
encryption is used and public key is used for encryption, there is no
confidence of sender. However if sender uses private key for encryption, both
confidentiality and authentication is provided. But still we need to recognize
corrupted messages
3.15.1 MAC
A cryptographic message authentication code (MAC) is a short piece of information

used to authenticate a message. A MAC algorithm accepts as input a secret
key and an arbitrary-length message to be authenticated, and outputs a MAC
(sometimes known as a tag). The MAC value protects both a message's
integrity as well as its authenticity, by allowing verifiers (who also possess the
secret key) to detect any changes to the message content.
A MAC is a cryptographic checksum
MAC = CK(M)
76
MAC is a many-to-one function. Potentially many messages have same MAC. But
finding these needs to be very difficult
Requirements for MAC
1. Knowing a message and MAC, is infeasible to find another message

with same MAC
2. MACs should be uniformly distributed
3. MAC should depend equally on all bits of the message
3.15.2 HASH Functions
A hash function H is a transformation that takes a variable-size input m and returns a

fixed-size string, which is called the hash value h (that is, h = H(m)). Hash functions
with just this property have a variety of general computational uses, but when
employed in cryptography the hash functions are usually chosen to have some
additional properties.
The basic requirements for a cryptographic hash function are:
o the input can be of any length,

o the output has a fixed length,
o H(x) is relatively easy to compute for any given x ,
o H(x) is one-way,
o H(x) is collision-free.
77
A hash function H is said to be one-way if it is hard to invert, where "hard to invert"

means that given a hash value h, it is computationally infeasible to find some input x
such that H(x) = h.
If, given a message x, it is computationally infeasible to find a message y not equal to

x such that H(x) = H(y) then H is said to be a weakly collision-free hash function.
A strongly collision-free hash function H is one for which it is computationally

infeasible to find any two messages x and y such that H(x) = H(y).
3.16. DIGITAL SIGNATURE
Digital signature (or public-key digital signature) is a type of method for

authenticating digital information analogous to ordinary physical signatures on
paper, but implemented using techniques from the field of public-key
cryptography. A digital signature method generally defines two
complementary algorithms, one for signing and the other for verification, and
the output of the signing process is also called a digital signature. Digital
signature has also been used as a broader term encompassing both public-key
digital signature techniques and message authentication codes.
Instead of encrypting the data itself, the signing software creates a one-way hash of
the data, then uses the private key to encrypt the hash. The encrypted hash, along with
other information, such as the hashing algorithm, is known as a digital signature.
The figure shows a simplified view of the way a digital signature can be used to
validate the integrity of signed data.
78
Using a digital signature to validate data integrity
The figure shows two items transferred to the recipient of some signed data: the
original data and the digital signature, which is basically a one-way hash (of the
original data) that has been encrypted with the signer's private key. To validate the
integrity of the data, the receiving software first uses the signer's public key to decrypt
the hash. It then uses the same hashing algorithm that generated the original hash to
generate a new one-way hash of the same data. (Information about the hashing
algorithm used is sent with the digital signature, although this isn't shown in the
figure.) Finally, the receiving software compares the new hash against the original
hash. If the two hashes match, the data has not changed since it was signed. If they
don't match, the data may have been tampered with since it was signed, or the
signature may have been created with a private key that doesn't correspond to the
public key presented by the signer. If the two hashes match, the recipient can be
certain that the public key used to decrypt the digital signature corresponds to the
private key used to create the digital signature. Confirming the identity of the signer,
however, also requires some way of confirming that the public key really belongs to a
particular person or other entity
The significance of a digital signature is comparable to the significance of a

handwritten signature. Once you have signed some data, it is difficult to deny
doing so later--assuming that the private key has not been compromised or out
of the owner's control. This quality of digital signatures provides a high degree
of non repudiation--that is, digital signatures make it difficult for the signer to
79
deny having signed the data. In some situations, a digital signature may be as
legally binding as a handwritten signature.
QUESTIONS
1. What is cryptography?
2. What is a block cipher?
3. What is a Fiestel cipher?
4. What are weak keys?
5. What is DES?
6. What is triple DES?
7. What are ECB and CBC modes?
8. What is Blowfish?
9. What is multiple encryption?
10. What is stream cipher?
11. What is public key cryptography?
12. What are the key management issues involved in public key cryptography?
13. What are certificates?
14. What are the advantages of public key cryptography over symmetric key
cryptography?
15. What is a one-way function?
16. What is the significance of one way function in cryptography?
17. What is RSA?
18. What are the different types of attacks on RSA?
19. What is the RSA factoring challenge?
20. How is RSA used for authentication in practice?
21. What is Diffie Hellman key exchange?
22. What is the significance of factoring in cryptography?
23. What is the discrete logarithm problem?
24. What are MACs?
25. What is a hash function?
Unit 4
80
4.1 KERBEROS
Kerberos is a secure method for authenticating a request for a service in a computer

network. Kerberos was developed in the Athena Project at the Massachusetts Institute
of Technology (MIT). The name is taken from Greek mythology; Kerberos was a
three-headed dog who guarded the gates of Hades. Kerberos lets a user request an
encrypted "ticket" from an authentication process that can then be used to request a
particular service from a server. The user's password does not have to pass through
the network.
The three heads of Kerberos comprise the Key Distribution Center (KDC), the client
user and the server with the desired service to access. The KDC is installed as part of
the domain controller and performs two service functions: the Authentication Service
(AS) and the Ticket-Granting Service (TGS). As exemplified in Figure 1, three
exchanges are involved when the client initially accesses a server resource:
1. AS Exchange
2. TGS Exchange
3. Client Server(CS) Exchange
Source : www.microsoft.com
4.1.1 AS Exchange
81
When initially logging on to a network, users must negotiate access by providing a

log-in name and password in order to be verified by the AS portion of a KDC within
their domain. The KDC has access to Active Directory user account information.
Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT)
that is valid for the local domain. The TGT has a default lifetime of 10 hours and may
be renewed throughout the user's log-on session without requiring the user to re-enter
his password. The TGT is cached on the local machine in volatile memory space and
used to request sessions with services throughout the network.
4.1.2 TGS Exchange
The user presents the TGT to the TGS portion of the KDC when desiring access to a
server service. The TGS on the KDC authenticates the user's TGT and creates a ticket
and session key for both the client and the remote server. This information, known as
the service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS
approves of the client's request, a service ticket is generated for both the client and the
target server. The client reads its portion using the TGS session key retrieved earlier
from the AS reply. The client presents the server portion of the TGS reply to the
target server in the client/server exchange coming next.
4.1.3 Client/Server Exchange
Once the client user has the client/server service ticket, he can establish the session
with the server service. The server can decrypt the information coming indirectly
from the TGS using its own long-term key with the KDC. The service ticket is then
used to authenticate the client user and establish a service session between the server
and client. After the ticket's lifetime is exceeded, the service ticket must be renewed
to use the service.
4.2. X.509
82
A public-key certificate is a digitally signed statement from one entity, saying that the
public key (and some other information) of another entity has some specific value.
Now a Certification Authority (CA) can act as a Trusted Third Party. CAs are entities
that are trusted to sign (issue) certificates for other entities. It is assumed that CAs will
only create valid and reliable certificates as they are bound by legal agreements. There
are many public Certification Authorities, such as VeriSign, Thawte, Entrust, and so
on.
The main inputs to the certificate creation process are:

• Matched public and private keys, generated using some special tools.Only the
public key is ever shown to anyone else. The private key is used to sign data.
• We need to provide information about the entity being certified. This normally
includes information such as name and organizational address.
The X.509 standard defines what information can go into a certificate, and describes
how to write it down (the data format). All X.509 certificates have the following data,
in addition to the signature:
Version
This identifies which version of the X.509 standard applies to this certificate,
which affects what information can be specified in it. Thus far, three versions
are defined.
Serial Number
The entity that created the certificate is responsible for assigning it a serial
number to distinguish it from other certificates it issues. This information is
used in numerous ways, for example when a certificate is revoked its serial
number is placed in a Certificate Revocation List (CRL).
Signature Algorithm Identifier
This identifies the algorithm used by the CA to sign the certificate.
Issuer Name
The X.500 name of the entity that signed the certificate. This is normally a
CA. Using this certificate implies trusting the entity that signed this certificate.
Validity Period
83
Each certificate is valid only for a limited amount of time. This period is described
by a start date and time and an end date and time, and can be as short as a few
seconds or almost as long as a century. The validity period chosen depends on a
number of factors, such as the strength of the private key used to sign the
certificate or the amount one is willing to pay for a certificate. This is the expected
period that entities can rely on the public value, if the associated private key has
not been compromised.
Subject Name
The name of the entity whose public key the certificate identifies. This name uses
the X.500 standard, so it is intended to be unique across the Internet. This is the
Distinguished Name (DN) of the entity, for example,
CN=Java Duke, OU=Java Software Division, O=Sun Microsystems Inc,

C=US
(These refer to the subject's Common Name, Organizational Unit,

Organization, and Country.)
Subject Public Key Information
This is the public key of the entity being named, together with an algorithm
identifier which specifies which public key crypto system this key belongs to
and any associated key parameters.
X.509 Version 1 has been available since 1988, is widely deployed, and is the most
generic.
X.509 Version 2 introduced the concept of subject and issuer unique identifiers to
handle the possibility of reuse of subject and/or issuer names over time. Most
certificate profile documents strongly recommend that names not be reused, and that
certificates should not make use of unique identifiers. Version 2 certificates are not
widely used.
X.509 Version 3 is the most recent and supports the notion of extensions, whereby
anyone can define an extension and include it in the certificate
84
4.3. E-MAIL SECURITY ENHANCEMENTS

Following is the security enhancements for email
•confidentiality
–protection from disclosure
•authentication
–of sender of message
•message integrity
–protection from modification
•non-repudiation of origin
–protection from denial by sender
4.3.1 PGP
(For diagrams refer text book- William Stallings)
PGP is an official email security system. It was developed by Phil Zimmermann.PGP
is available on Unix, PC, Macintosh and Amiga systems. It is originally free, now
have commercial versions available also
4.3.1.1 How PGP works
Authentication
1.The sender creates a message
2.SHA-1 used to generate 160-bit hash code of message
3.The hash code is encrypted with RSA using the sender's private key, and result is
attached to message.
4.The receiver uses RSA or DSS with sender's public key to decrypt and recover hash
code
5.The receiver generates new hash code for message and compares with decrypted
hash code, if match, message is accepted as authentic
Confidentiality
85
1. The sender generates message and random 128-bit number to be used as session
key for this message only.
2.The message is encrypted, using CAST-128 / IDEA/3DES with session key.
3.The session key is encrypted using RSA with recipient's public key, then attached to
message.
4.The receiver uses RSA with its private key to decrypt and recover session key.
5.The session key is used to decrypt message.
Authentication & Confidentiality
1. Create signature & attach to message

2. Encrypt both message & signature
3. Attach RSA encrypted session key
Compression
By default PGP compresses message after signing but before encrypting and can store
uncompressed message & signature for later verification. It uses ZIP compression
algorithm.
Email- Compatibility
When using PGP we will have binary data to send (encrypted message etc).However
email was designed only for text. Hence PGP must encode raw binary data into
printable ASCII characters. For this it uses radix-64 algorithm, which maps 3 bytes to
4 printable characters and also appends a CRC
4.3.2 S/MIME
S/MIME is the name given to Secure MIME or Secure encryption of attachments

when they are added to email messages. S/MIME requires a both a private and public
key. The public key is stored and made available to those who wish to send users an
86
encrypted message. So to send a message via S/MIME the sender must look up the
public key in a global directory or already have it available. Once the key has been
found, the sender must encrypt the message/attachment and forward it to the
destination server.
In order for the message to be read, the encrypted message must be decoded by the
mail client or by the mail server. There are issues with either of these solutions:
• Decryption by the mail client. At the current time, not many mail clients
support S/MIME decryption. Further there is the issue of configuring the mail
client with the correct private key so that decryption works OK. Since
messages are stored encrypted, if the key becomes compromised at any point
in the future and must be changed, there is the risk that the messages will
become unavilable in the future.
• Decryption by the mail server. This requires the server to hold both the
encryption and decryption key for each user. Clearly there will be additional
load on the server as it manages each message and messages are likley to be
stored unencrypted on the server itself (there is no point in them being
encrypted since the key is available on the server).
4.4. SECURE SOCKET LAYER
The Secure Sockets Layer protocol is a protocol layer which may be placed between a
reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application
protocol layer (e.g. HTTP). SSL provides secure communication between client and
server by allowing mutual authentication, the use of digital signatures for integrity,
and encryption for privacy. The protocol is designed to support a range of choices for
specific algorithms used for cryptography, digests, and signatures. Choices are
negotiated between client and server at the start of establishing a protocol session.
Version: Source: Description:
87
SSL v2.0 Vendor Standard First SSL protocol for which implementations exists
(from Netscape
Corp.)
SSL v3.0 Expired Internet Revisions to prevent specific security attacks, add non-
Draft (from RSA ciphers, and support for certificate chains
Netscape Corp.)
TLS v1.0 Proposed Internet Revision of SSL 3.0 to update the MAC layer to
Standard (from HMAC, add block padding for block ciphers, message
IETF) order standardization and more alert messages.
There are a number of versions of the SSL protocol, as shown. SSL 3.0 is the basis for
the Transport Layer Security protocol standard, currently in development by the
Internet Engineering Task Force (IETF).
4.4.1 Session Establishment
The SSL session is established by following a handshake sequence between client and
server. This sequence may vary, depending on whether the server is configured to
provide a server certificate or request a client certificate. Though cases exist where
additional handshake steps are required for management of cipher information, this
article summarizes one common scenario: see the SSL specification for the full range
of possibilities. Once an SSL session has been established it may be reused, thus
avoiding the performance penalty of repeating the many steps needed to start a
session. For this the server assigns each SSL session a unique session identifier which
is cached in the server and which the client can use on forthcoming connections to
reduce the handshake.
88
The elements of the handshake sequence, as used by the client and server, are listed
below:
1. Negotiate the Cipher Suite to be used during data transfer

2. Establish and share a session key between client and server
3. Optionally authenticate the server to the client
4. Optionally authenticate the client to the server
The first step, Cipher Suite Negotiation, allows the client and server to choose a
Cipher Suite supportable by both of them. The SSL3.0 protocol specification defines
31 Cipher Suites. A Cipher Suite is defined by the following components:
• Key Exchange Method

• Cipher for Data Transfer
• Message Digest for creating the Message Authentication Code (MAC)
These three elements are described in the sections that follow.
4.4.2 Key Exchange Method
The key exchange method defines how the shared secret symmetric cryptography key
used for application data transfer will be agreed upon by client and server. SSL 2.0
uses RSA key exchange only, while SSL 3.0 supports a choice of key exchange
89
algorithms including the RSA key exchange when certificates are used, and Diffie-
Hellman key exchange for exchanging keys without certificates and without prior
communication between client and server. One variable in the choice of key exchange
methods is digital signatures -- whether or not to use them, and if so, what kind of
signatures to use.
4.4.3 Cipher for Data Transfer
SSL uses the conventional cryptography algorithm (symmetric cryptography)

described earlier for encrypting messages in a session. There are nine choices,
including the choice to perform no encryption:
• No encryption
• Stream Ciphers
o RC4 with 40-bit keys
o RC4 with 128-bit keys
• CBC Block Ciphers
o RC2 with 40 bit key
o DES with 40 bit key
o DES with 54 bit key
o Triple-DES with 168 bit key
o Idea (128 bit key)
4.4.4 SSL Record Protocol - Architecture
HTTP FTP SMTP
SSL SSL change SSL alert

handshake cipher spec protocol
protocol protocol
SSL Record Protocol
90
TCP
IP
SSL Record Protocol takes care of the data transmission. SSL Record Protocol
provides two services, confidentiality and integrity. Confidentiality uses symmetric
encryption with a shared secret key defined by Handshake Protocol and integrity uses
a MAC with shared secret key.SSL is used to transfer application and SSL Control
data between the client and server. It possibly fragments the data into smaller units,
compress the data, attach signatures and encrypt these units before transmitting them.
4.5. IPSec
IPSec is a group of protocols developed by IETF. The group includes the

Authentication Header (AH), which addresses authentication for IP traffic, and the
Encapsulating Security Payload (ESP), which defines encryption for IP data. AH
ensures that the packet has not been altered during transmission. It can be used in
combination with ESP or it simply just use to verify the authenticity of a regular IP
packet. The AH also allows the receiver to verify the identity of the sender. IPSec
provides these at the IP layer and its often nowadays build on the networks card from
91
the beginning. IPSec can be used to protect one or more data flows between a pair of
hosts, gateways and between both gateways and hosts.
Key management for IPsec: ISAKMP and IKE
ISAKMP (Internet Security Association and Key Protocol Management) is designed

to negotiate, establish, modify and delete security associations and their attributes.
ISAKMP is a generic framework which does not dependent on the mechanisms in

favor of which the negotiation takes place.
IKE is used to handle negotiation of protocols and algorithms that are based on local
policy that generate the encryption and the authentication. Some of these is DES,
MD5, AH and SHA. IKE provides a authentication of the IPSec peers and establishes
the IPSec key.
DES (The Data Encryption Standard) is used to encrypt the packet data. DES use
cipher block chaining to initialize a vector to start the encryption.
SHA (Secure Hash Algorithm) and MD5 (Message Digest 5) are hash algorithms and
these are used to authenticate the data.
ESP (Encapsulating Security Payload) is the protocol that handles encryption of IP

data. It uses symmetric, or secret key, cryptographic algorithms like Data Encryption
Standard (DES), and triples DES to encrypt the payload. The default method is 56-bit
DES.
4.5.1 Encapsulating Security Payload
92
ESP includes several parts, the first of which is the control header that contains the
SPI and the sequence number field. The SPI and sequence number serve the same
purpose as in the AH. The SPI indicates which security algorithms and keys were
used for a particular connection, and the sequence number keeps track of the order in
which packets are transmitted. The payload data can be of any size because it's the
actual data being carried by the packet. Along with the payload data, the ESP also
contains 0 bytes to 255 bytes of padding, which ensures the data, will be of the correct
length for particular types of encryption algorithms. This area of the ESP also
includes the pad length, which tells how much padding is in the payload, and the next
header field, which gives information about the data and the protocol used.
Authentication data is the field that contains a digital signature that has been applied
to everything in the ESP except the authentication data itself.
4.5.2 Authentication Header
Authentication Header is a security protocol that

provides authentication and optional replay-
detection services. AH is embedded in the data to
be protected AH can be used either by itself or with Encryption Service Payload
(ESP). The first field in the AH is the next header field; this is an 8-bit field that tells
which higher-level protocol (such as UDP, TCP, or ESP) follows the AH. The
payload length is an 8-bit value that indicates the length of the authentication data
field in 32-bit words. The Security Parameters Index is a 32-bit number that tells the
packet recipient which security protocols the sender is using. This information
includes which algorithms and keys are being applied by the sending device. The
sequence number tells how many packets with the same parameters have been sent.
This number acts as a counter and is incremented each time a packet with the same
SPI is bound for the same address. Authentication data is a digital signature for the
93
packet. To authenticate users, the AH can use either Message Digest 5 algorithm or
the Secure Hash Algorithm.
4.5.3 Operating modes
There are two different modes in IPsec, transport mode and tunnel mode.
In Transport mode, only the data from the upper-layer protocol and the data
transported by the IP datagrams are protected. This mode is usable only on final
equipment.
In tunnel mode, the IP header is also protected (authentication, integrity and/or
confidentiality) and is replaced by a new header. This new header is used to transport
the packet to the end of the tunnel, where the original header is restored. Tunnel mode
is usable either on final equipment or on security gateways. This mode makes it
possible to ensure a more significant protection against traffic analysis.
4.6. FIREWALLS
A firewall is simply a group of components that collectively form a barrier between

two networks. A firewall is a piece of hardware and/or software which functions in a
networked environment to prevent some communications forbidden by the security
policy.
4.6.1 Terminologies
Bastion host.
A general-purpose computer used to control access between the internal
(private) network (intranet) and the Internet (or any other untrusted network).
Router.
A special purpose computer for connecting networks together. Routers also
handle certain functions, such as routing , or managing the traffic on the
networks they connect.
Access Control List (ACL).
Many routers now have the ability to selectively perform their duties, based on
a number of facts about a packet that comes to it. This includes things like
origination address, destination address, destination service port, and so on.
94
These can be employed to limit the sorts of packets that are allowed to come
in and go out of a given network.
Demilitarized Zone (DMZ).

The DMZ is a critical part of a firewall: it is a network that is neither part of
the untrusted network, nor part of the trusted network. But, this is a network
that connects the untrusted to the trusted. The importance of a DMZ is
tremendous: someone who breaks into your network from the Internet should
have to get through several layers in order to successfully do so. Those layers
are provided by various components within the DMZ.
Proxy.
This is the process of having one host act in behalf of another. A host that has
the ability to fetch documents from the Internet might be configured as a
proxy server, and host on the intranet might be configured to be proxy clients.
All hosts on the intranet are able to access resources on the Internet without
having the ability to direct talk to the Internet.
4.6.2 Types of Firewalls
Application Gateways
The first firewalls were application gateways, and are sometimes known as proxy
gateways. These are made up of bastion hosts that run special software to act as a
proxy server. This software runs at the Application Layer of the ISO/OSI Reference
Model, hence the name. Clients behind the firewall must be proxitized (that is, must
know how to use the proxy, and be configured to do so) in order to use Internet
services. Traditionally, these have been the most secure, because they don't allow
anything to pass by default, but need to have the programs written and turned on in
order to begin passing traffic.
Packet Filtering
Packet filtering is a technique whereby routers have ACLs (Access Control Lists)
turned on. By default, a router will pass all traffic sent it, and will do so without any
95
sort of restrictions. Employing ACLs is a method for enforcing security policy with
regard to what sorts of access you allow the outside world to have to your internal
network, and vice versa. There is less overhead in packet filtering than with an
application gateway, because the feature of access control is performed at a lower
ISO/OSI layer (typically, the transport or session layer). Due to the lower overhead
and the fact that packet filtering is done with routers, which are specialized computers
optimized for tasks related to networking, a packet filtering gateway is often much
faster than its application layer.
4.7. SECURITY MECHANISMS IN JAVA PLATFORM
Java applets are far more powerful than the usual HTML code served up on the Web.
When not restricted by applet-security measures, Java is a complete and powerful
programming language capable of sending information over the network; reading,
altering, or deleting files; using system resources; and so on. This is powerful stuff,
and in the hands of a malicious programmer. Java should restrict itself such that the
full power and potential of the Java language is not misused. Java applets we retrieve
from the Web have been written by someone else, we cannot trust them to perform
with integrity. Java downloaded from the Net is automatically considered untrusted
code. In order to ensure that untrusted code does nothing mischievous, it is important
to limit what that untrusted code can do.
Following are the basic categories of potential attacks Java applets could facilitate:
ATTACK EXPLANATION AND JAVA

CLASS CONSEQUENCES DEFENSE
The most severe class of attacks.
System Applets that implement such attacks
Strong
Modification are attack applets. Consequences of
these attacks: severe.
Invasion of If you value your privacy, this attack Strong
Privacy class may be particularly odious. They
are implemented by malicious applets.
Include mail forging. Consequences
96
of these attacks: moderate.

Also serious but not severely so, these
attacks can bring a machine to a
Denial of standstill. Also implemented by
Weak
Service malicious applets. May require reboot.
Consequences of these attacks:
moderate.
Merely annoying, this attack class is
the most commonly encountered.
Implemented by malicious applets.
Antagonism Weak
May require restart of browser.
Consequences of these attacks: light
to moderate.
4.7.1 Java Sandbox Architecture
The default sandbox is made of three interrelated parts: the Verifier, the Class Loader,
and the Security Manager. If any of the three parts breaks, the entire security system
breaks. The Verifier is built in to the VM and cannot be accessed by Java
programmers or Java users. In most Java implementations, when Java code arrives at
the VM and is formed into a Class by the Class Loader, the Verifier automatically
examines it. The Verifier checks byte code at a number of different levels. The
simplest test makes sure that the format of a code fragment is correct. If the Verifier
discovers a problem with a class file, it throws an exception, loading ceases, and the
class file never executes. The verification process, in concert with the security
features built into the language and checked at runtime, helps to establish a base set of
security guarantees. The Verifier also ensures that class files that refer to each other
preserve binary compatibility. There are rules of compatibility that govern the ability
to change use of classes and methods without breaking binary compatibility. For
example, it is okay to add a method to a class that is used by other classes, but not
okay to delete methods from a class used by other classes. The Verifier enforces
compatibility rules. Once byte code passes through verification, the following things
are guaranteed:
97
• The class file has the correct format

• Stacks will not be overflowed or under flowed
• Byte code instructions all have parameters of the correct type.
• No illegal data conversions (casts) occur
• Private, public, protected, and default accesses are legal
The Verifier acts as the primary gatekeeper in the Java security model. It ensures that
each piece of byte code downloaded from the outside plays by the rules. That way, the
Java VM can safely execute byte code that may not have been created by a Java
compiler. When the Verifier finds a problem in a class, it rejects the malformed class
and throws an exception. This is obviously a much more reasonable behavior than
running buggy or malicious code that crashes the VM.
All Java objects belong to classes. Class loaders determine when and how classes can
be added to a running Java environment. Part of their job is to make sure that
important parts of the Java runtime environment are not replaced by impostor code.
Class loaders perform two functions. First, when the VM needs to load the byte code
for a particular class, it asks a class loader to find the byte code. Each class loader can
use its own method for finding requested byte code files: It can load them from the
local disk, fetch them across the Net using any protocol, or it can just create the byte
code on the spot. This flexibility is not a security problem as long as the party who
wrote the code that is being loaded trusts the class loader. Second, class loaders define
the namespaces seen by different classes and how those namespaces relate to each
other. Namespace is a set of unique names of classes loaded by a particular Class
Loader and a binding of each name to a specific class object. Applet Class Loaders,
which are typically supplied by the browser vendor, load all applets and the classes
they reference, usually getting the classes from HTTP servers. When an applet loads
across the network, its Applet Class Loader receives the binary data and instantiates it
as a new class. Under normal operation, applets are forbidden to install a new Class
Loader
Summary
Each Java class begins as source code. This is then compiled into byte code and
distributed to machines anywhere on the Net. A Java-enabled browser automatically
98
downloads a class when it encounters the <APPLET> tag in an HTML document. The
Verifier examines the byte code of a class file to ensure that it follows Java's strict
safety rules. The Java VM interprets byte code declared safe by the Verifier. The Java
specification allows classes to be unloaded when they are no longer needed, but few
current Java implementations unload classes.
Java's ability to dynamically load classes into a running Java environment is fraught
with security risks. The class-loading mechanisms mitigate these risks by providing
separate namespaces set up according to where mobile code originates. This
capability ensures that essential Java classes cannot be spoofed (replaced) by external,
untrusted code. The Applet Class Loader in particular is a key piece of the Java
security model.
4.7.2 Security Manager
The third part of the base Java security model is the Security Manager. This part of
the security model restricts the ways an applet uses visible interfaces (Java API calls).
The Security Manager implements a good portion of the entire security model and is
the part of the security model most often encountered (in terms of a
SecurityException) by Java applet developers.
The job of the Security Manager is to keep track of who is allowed to do which
dangerous operations. A standard Security Manager will disallow most operations
when they are requested by untrusted code, and will allow trusted code to do whatever
it wants.
The Security Manager is a single Java object that performs runtime checks on
dangerous methods. Code in the Java library consults the Security Manager whenever
a potentially dangerous operation is attempted. The Security Manager can veto the
operation by generating a SecurityException. Decisions made by the Security
Manager take into account the origin of the requesting class. Obviously, built-in
classes are usually given more privilege than classes loaded across the Net. The
Security Manager makes the final decision as to whether a particular operation is
permitted or rejected. The Java API provides all calls necessary to interface to the
operating system, thus making isolation of all required security checks possible within
99
the API. When a dangerous call is made to the Java library, the library queries the
Security Manager. These queries use a set of methods that check access.
Each VM can have only one Security Manager installed at a time, and once a Security
Manager has been installed it cannot be uninstalled (except by restarting the VM).
Java-enabled applications such as Web browsers install a Security Manager as part of
their initialization, thus locking in the Security Manager before any potentially
untrusted code has a chance to run.
Source : www.securingjava.com
4.7.3 What the Security Manager Is Set Up to Do for Untrusted Applets
The Security Manager has the following duties:
• Prevent installation of new class loaders. The job of class loaders is to keep
the namespaces properly organized. Because security checks are requested by
classes in the Java library, applets must be prevented from spoofing the library
classes.
• Protect threads and thread groups from each other.
• Control the execution of other application programs.
• Control the ability to shut down the VM.
• Control access to other application processes.
• Control access to system resources such as print queues, clipboards, event
queues, system properties, and windows.
• Control file system operations such as read, write, and delete. Access to local
files is strictly controlled.
• Control network socket operations such as connect and accept.
100
• Control access to Java packages (or groups of classes), including access to

security enforcement classes.
Unit 5
5.1. TYPES OF SECURITY
Database security is a very broad area that addresses many issues like:
101
1. Legal and ethical issues regarding the right to access information.

2. Policy issues at the governmental, institutional or corporate level as to what
kinds of information should not be made publicly available.
3. System related issues such as the system levels at which various security
functions should be enforced.
4. The need in some organizations to identify multiple security levels and to
categorize the data and users based on these classifications.
5.2. THREATS TO DATABASES

Important security goals are integrity, availability and confidentiality. Threats to
databases result in the loss of degradation of some or all of the security goals.
1. Loss of integrity – Database security refers to the requirement that information
be protected from improper modification. Modification of data includes
insertion, deletion, updation etc. Integrity is lost if unauthorized changes are
made to data by either intentional or accidental acts.
2. Loss of availability – Database availability refers to making objects available
to a human user or a program to which they have a legitimate right. Loss of
availability is a serious threat to database security.
3. Loss of confidentiality – Database confidentiality refers to the protection of
data from unauthorized disclosure. Unauthorized access to data can lead to
loss of database security.
To protect databases against these types of threats four kinds of countermeasures
can be implemented:
1. Access control – The security mechanism of a DBMS must include provisions
for restricting access to the database system as a whole. This function is called
access control and is handled by creating user accounts and passwords to
control the login process by the DBMS.
2. Inference control – Statistical database is used to provide statistical
information or summaries of values based on various criteria. For e.g. a
database for population statistics based on age groups, income level and other
criteria. It is sometimes possible to deduce or infer certain facts concerning
individuals from queries that involve only summary statistics on groups; this
must not be permitted. This problem is called statistical database security. The
corresponding counter measures are called inference control measures.
102
3. Flow control – It prevents information from flowing in such a way that it

reaches unauthorized users. Channels that are pathways for information to
flow implicitly in ways that violate security policy of an organization are
called covert channels.
4. Data Encryption – It is used to protect sensitive data that is being transmitted
via some type of communications network. Encryption is also used for
providing additional protection for sensitive portions of a database. The data is
encoded using some coding algorithm.
In a multiuser database system, the DBMS must provide techniques to enable

certain user or user groups to access selected portions of a database without
gaining access to the rest of the database. A DBMS includes a database security
and authorization subsystem that is responsible for ensuring the security portions
of a database against unauthorized access. There are two types of database
security mechanisms:
1. Discretionary security mechanisms – These are used to grant privileges to
users, including the capability to access specific data files, records or fields in
specified mode.
2. Mandatory security mechanisms – These are used to enforce multilevel
security by classifying the data and users into various security classes (or
levels) and then implementing the appropriate security policy of the
organization.
5.3. DATABASE ADMINISTRATOR (DBA)
DBA is the central authority for managing a database system. The DBA has a
DBA account which is also called a system or superuser account, which provides
powerful capabilities that are not made available to regular database accounts and
users. DBA has privileged commands for performing actions like:
1. Account creation – This action creates a new account and password for a user
or a group of users to enable access to the DBMS.
2. Privilege granting – This action permits the DBA to grant certain privileges to
certain accounts.
3. Privilege revocation – This action permits the DBA to revoke (cancel) certain
privileges that were preciously given to certain accounts.
103
4. Security level assignment – This action consists of assigning user accounts to

the appropriate security classification level.
5.4. ACCESS PROTECTION, USER ACCOUNTS & DATABASE AUDITS

Whenever a person or group of persons needs to access a DBMS, the individual or
group must apply for a user account. The DBA will then create a new account number
and password for the user if there is a legitimate need to access the database. The user
must log into the DBMS by entering the account number and password whenever
database access is needed. The DBMS checks that the account number and password
are valid; if they are, the user is permitted to use the DBMS.
To keep track of database users and their accounts and passwords there
is an encrypted table or file with two fields – account number and password.
Whenever a new account is created, a new record is inserted into the table. When an
account is canceled, the corresponding record is deleted from the table.
The database system must also keep track of all operations on the
database that are applied by a certain user throughout each login session, which
consists of the sequence of database interactions that a user performs from the time of
logging in to the time of logging off. When a user logs in, the DBMS can record the
user’s account number and associate it with the terminal from which the user logged
in. All operations applied from that terminal are attributed to the user’s account until
the user logs off.
To keep track of all updates applied to the database, a system log is
maintained. It includes an entry for each operation applied to the database that may be
required for recovery from a transaction failure or system crash.
If any tampering with the database is suspected, a database audit is
performed, which consists of reviewing the log to examine all accesses and operations
applied to the database during a certain time period. When an illegal or unauthorized
operation is found, the DBA can determine the account number used to perform this
operation. A database log that is used mainly for security purpose is called an audit
trail.
5.5. TYPES OF DISCRETIONARY PRIVILEGES

There are two levels of assigning privileges to use the database system:
104
1. The account level – At this level, the DBA specifies the particular privileges
that each account holds independently of the relations in the database.
The privileges at the account level are
a) Create schema or Create table - To create a schema or base relation.
b) Create view – To create virtual relations.
c) Alter - To apply schema changes such as adding or removing attributes from
relations.
d) Drop - To delete relations or views.
e) Modify - To insert, delete, or update tuples
f) Select - To retrieve information from the database by using a SELECT query.
2. The relation (or table) level – At this level, the DBA can control the privilege
to access each individual relation or view in the database. The relation level
privileges are applied to base relations or virtual relations (views). Privileges at
the relation level specify for each user the individual relations on which each type
of command can be applied.
Access Matrix Model

The granting and revoking of privileges generally follow an authorization
model for discretionary privileges known as access matrix model. In this model the
rows of a matrix M represent subjects (users, accounts and programs) and the columns
represent objects (relations, records, columns, views, operations). Each position M (i,
j) in the matrix represents the types of privileges (read, write, update) that subject i
holds on object j.
To control the granting and revoking of privileges, each relation R in a
database is assigned an owner account. The owner is given all privileges. The owner
account holder can pass privileges to other users by granting privileges to their
accounts. In SQL, the following types of privileges can be granted:
1. SELECT – This gives the account the privilege to use select statement.
2. MODIFY – This gives the account the privilege to use insert, update
and delete statements.
3. REFERENCES – This gives the account the capability to reference
relation R when specifying integrity constraints.
Specifying Privileges using views
105
If the owner A of a relation R wants another account B to be able to retrieve only

some fields of R, then A can create a view V of R that includes only those attributes
and then grant SELECT on V to B.
Revoking Privileges
The owner of a relation may want to grant certain privileges to a user for a specific
task and then revoke those privileges, once the task is completed. In SQL, REVOKE
command is used for canceling privileges.
Propagation of privileges using the GRANT option

Whenever the owner A of a relation grants a privilege on R to another account B, the
privilege can be given to B with or without the ‘GRANT OPTION’. If the GRANT
OPTION is given, this means that B can also grant the privilege on R to other
accounts.
Suppose that B is given the GRANT OPTION by A and that B then grants the
privilege on R to a third account C, also with GRANT OPTION. In this way,
privileges on R can propagate to other accounts without the knowledge of the owner
of R. If the owner account A now revokes the privilege granted to B, all the privileges
that B propagated based on that privileges should automatically be revoked by the
system. It is possible for a user to receive a certain privilege from two or more
resources. For e.g. A4 may receive a certain ‘update R’ privilege from both A2 and
A3. In such a case, if A2 revokes this privilege from A4, A4 will still continue to have
the privilege by virtue of having been granted it from A3. If A3 later revokes the
privilege from A4, A4 totally loses the privilege.
E.g. 1. GRANT createtab to A1 ---- Gives A1 the privilege to create tables.
2. GRANT INSERT, DELETE ON EMPLOYEE, DEPT to A2 ------ gives the
privilege to perform insert and delete operations on Employee and Dept
tables.
3. GRANT SELECT ON EMPLOYEE to A3 with GRANT OPTIION ---- gives
A3 the privilege to perform select operation.
4. REVOKE SELECT ON EMPLOYEE FROM A3 ---- revokes the privilege to
perform SELECT operation on EMPLOYEE from A3.
Specifying limits on propagation of Privileges
106
1. Horizontal propagation – Limiting horizontal propagation to an integer

number i means that an account B given the GRANT OPTION can grant the
privilege to at most i other accounts.
2. Vertical propagation – Granting a privilege with a vertical propagation of zero
is equivalent to granting the privilege with no GRANT OPTION. If account A
grants a privilege to account B with the vertical propagation set to an integer
number j>0, this means that the account B has the GRANT OPTION on that
privilege, but B can grant privilege to other accounts only with a vertical
propagation less than j.
5.6. MANDATORY ACCESS CONTROL FOR MULTILEVEL SECURITY

MAC require the classifications of users and data values into security classes and
enforce the rules that prohibit flow of information from higher to lower security
levels. Typical security classes are top secret (TS), secret (S), confidential (C) and
unclassified (U), where TS is the highest level and U is the lowest.
TS > S > C > U
The commonly used model for multilevel security known as Bell – LaPadula model
classifies each subject (user, account and program) and object (relation, tuple,
column, view, operation) into one of the security classifications TS, S, C or U. The
clearance (classification) of a subject S is referred as class (S) and the classification of
an object O as class (O). Two restrictions are enforced on data access based on the
subject/object classifications.
1. A subject S is not allowed to read access to an object O unless class (S) >
class (O). This is known as the simple security property.
2. A subject S is not allowed to write an object O unless class (S) < class (O).
This is known as the star property.
The first rule enforces that no subject can read an object whose security classification
is higher than the subject’s security clearance. The second rule prohibits a subject
from writing an object at a lower security classification than the subject’s security
clearance. Violation of this rule would allow information to flow from higher to lower
classifications. For e.g. a user (subject) with TS clearance may make a copy of an
object with classification TS and then write it back as a new object with classification
U, thus making it visible throughout the system.
107
To incorporate multilevel security notions into the relational database

model, it is common to consider attribute values and tuples as data objects. Hence
each attribute A is associated with a classification attribute C in the schema and each
attribute value in a tuple is associated with a corresponding security classification. In
addition, in some models, a tuple classification attribute TC is added to the relation
attributes to provide a classification for each tuple as a whole. Hence, a multilevel
relation schema R with n attributes can be represented as
R (A1, C1, A2, C2……….An, Cn, TC)
Where each Ci represents the classification attribute associated with the attribute Ai.
Apparent key - The apparent key of a multilevel relation is the set of attributes that
would have formed the primary key in a regular (single-level) relation.
Filtering – The process of producing tuples at a lower classification level from a

single tuple of a relation stored at a higher classification level.
Polyinstantiation – It is the state at which several tuples can have the same apparent
key value but have different attribute values for users at different classification levels.
Consider an e.g.
Employee
Name Salary Job Performance TC
Smith U 40000 Fair S S
C
Brown C Good C S
80000 S
Fig (1)
Assume that the Name attribute is the apparent key. Now consider a select query
‘select * from employee’.
Case 1: A user with security clearance S would see the original relation as it is, i.e.

C
Brown C Good C S
108
80000 S
Fig (2)
Case 2: A user with security clearance C would see the relation as:

Smith U 40000 null C C
C
Brown C Good C C
80000
C
Fig (3)
Case 3: A user with security clearance U would see the relation as:
Smith U null U null U

U
Fig (4)
Thus we can see that filtering introduces null values for attribute values whose
security classification is higher than the user’s security clearance.
The entity integrity rule for multilevel relations state that all attributes
that are members of the apparent key must not be null and must have the same
security classification within each individual tuple. In addition, all other attribute
values in the tuple must have a security classification greater than or equal to the
apparent key.
Suppose that a user with security clearance C tries to update the value of
‘JobPerformance’ of Smith to ‘Excellent’; the SQL statement would be
Update employee
Set JobPerformance = ‘Excellent’
109
Where Name = ‘Smith’
Since the view provided to users with security clearance

C (Fig. 3) permits such an update, the system should not reject it; otherwise the user
could infer that some non null value exists for the ‘JobPerformance’ attribute of Smith
rather than the null value that appears. This type of inference should not be permitted
in highly secure systems. The solution is to create a polyinstantiation for the Smith
tuple at the lower classification level C as shown below:

C
Smith U Excellent C C
40000
Brown C C Good C S
80000 S
This is necessary since the new tuple cannot be filtered from the existing tuple of
classification S.
5.7. INTRODUCTION TO STATISTICAL DATABASE SECURITY
Statistical databases are used mainly to produce statistics on various populations. (A
population is a set of tuples of a relation that satisfy some selection condition). The
database may contain confidential data, which should be protected from user access.
However, users are permitted to retrieve statistical information on populations, such
as sum, average, maximum, minimum and standard deviation. i.e. statistical database
users are not allowed to retrieve individual data but are allowed to access statistical
data as a whole. Statistical database security techniques must prohibit the retrieval of
individual data. This can be controlled by prohibiting queries that retrieve attribute
values and by allowing only queries that involve statistical aggregate functions such
as COUNT, SUM, MIN, MAX, AVERAGE and STANDARD DEVIATION. Such
queries are called statistical queries.
In some cases it is possible to infer the values of individual tuples from a sequence of
statistical queries. As an e.g. consider the two statistical queries:
110
Q1: select count (*) from person where <condition>;

Q2: select avg (income) from person where <condition>;
Suppose that we are trying to find the salary of ‘Jane Smith’ and we know that she has
a PH.D. Degree and she lives in the city of Bellaire, Texas. We issue query Q1 in the
following condition: (Last_degree = ‘PH.D.’ and Sex = ‘F’ and City = ‘Bellaire’ and
State = ‘Texas’). If we get a result of 1 for this query, we can issue Q2 with the same
condition and find the income of ‘Jane Smith’. Even if the result of Q1 on the
preceding condition is not 1 but is a small number say 2 or 3, we can issue statistical
queries using the functions MAX, MIN and AVERAGE to identify the possible range
of values for the income of ‘Jane Smith’.
The possibility of inferring individual information from statistical queries
is reduced if no statistical queries are permitted whenever the number of tuples in the
population specified by the selection condition falls below some threshold. Another
technique for prohibiting retrieval of individual information is to prohibit sequences
of queries that refer repeatedly to the same population of tuples.
REFERENCES
1. Module1, 4 Network Security Essentials Applications & Standards,

William S., Pearson Education Asia
2. Module2 Modern operating System, Andrew S. Tanenbaum, Pearson
Education Asia
3. Using JAVA 2 platform, Joseph L. Weber, Prentice Hall of India
111
4. Module3 Cryptography and network security principles and practice,

William Stallings, Pearson Education Asia
5. Information theory coding and cryptography, Ranjan Bose, TMH
6. Module 4,5 Designing security Architecture Solutions, Jay
Ramachandran, Wiley Dreamtech
7. Module5 Database Security Mechanisms for Computer Network, Sead
Muftic, John wiles
112

Sic

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sic

Uploaded by

Copyright:

Available Formats

Security In Computing

Security refers to any measures taken to protect something. Examples of

Network security consists of the provisions made in an underlying computer network

1.1 Threats in Network Security

Organizations maintain valuable information on their computer systems. This

Valuable information may become worthless if unauthorized information is mixed

Unauthorized use of resources

Unauthorized use of resources may lead to destruction, modification, loss of integrity

Authorized use of resources may give authorized individuals the opportunity to

Unauthorized information flow

Repudiation of information flow

Repudiation of information flow involves denial of transmission or receipt of

1.2 SECURITY SERVICES

In order to protect against perceived threats, various security services need to be

Confidentiality is the protection of transmitted data from passive attack. With

When the information is in a protected form, it is called a cipher text. Cipher

Integrity can apply to a stream of messages, a single message, or selected

Non repudiation prevents either sender or receiver from denying a transmitted

A variety of attacks can result in a form of reduction in availability. Some of

1.3 SECURITY MECHANISM

1.4 SECURITY ATTACKS

Ref: http://www.cse.ohio-state.edu/~anish/694KNotes/694Lecture0.ppt#473,9,Security Attacks

Attacks can be active or passive

• Involve modification of data stream or creation of a false stream.

• Subdivided into four categories: masquerade, replay, modification of

Masquerade: One entity pretends to be a different entity. e.g., Authentication

Modification of message: Some portion of message altered, or delayed or

Denial of Service: Prevents normal use or management of communication

Other active attacks include:

1.5 HACKERS AND CRACKERS

For further reading: http://en.wikipedia.org/wiki/Hacker

For further reading: http://en.wikipedia.org/wiki/Cracker_%28computing%29

1.6 COMMON INTRUSION TECHNIQUES

A computer virus behaves in a way similar to a biological virus, which

malicious software. Computer viruses cannot directly damage hardware, only

File or Program Virus

In April 1994, the Pathogen computer virus was released in the

For further reading: http://en.wikipedia.org/wiki/Computer_virus

In addition to replication, a worm may be designed to do any number of

For further reading: http://en.wikipedia.org/wiki/Computer_worm

For further reading: http://en.wikipedia.org/wiki/Trojan_horse_(computing)

For further reading: http://en.wikipedia.org/wiki/Logic_bomb

2.1.1 The Security Environment:

Data Loss is mainly caused by

1. Acts of God (fires, floods, earthquakes)

Intruders come in 2 varieties:

Another aspect of Security problem is Privacy: protecting individuals from misuse of

2.1.2 The Internet Worm:

2.1.3 Generic Security Attacks:

A Virus is a program fragment that is attached to a legitimate program with the

2.1.4 Design Principles for Security:

v. The protection mechanism should be simple, uniform and built in to the

2.1.5 User Authentication:

2.2.1 Protection Domains

Domain 1 Domain 2 Domain 3

Fig 2.1: Three Production Domains.

protection domain. In other words, there is some collection of objects it can

File 1 File 2 File 3 File 4 File 5 File 6 Printer 1 Plotter 2

Fig 2.2: A Protection Matrix.

File File File File File File Printe Plotte D1 D2 D3

Fig 2.3: A protection matrix with domains as objects.

A typical capability list is shown below:

Each capability has a: