Sic

Security In Computing

Unit 11.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

http://en.wikipedia.org/wiki/Cracker_(computing)

http://catb.org/~esr/faqs/hacker-howto.html

http://en.wikipedia.org/wiki/Hacker


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

http://www.webopedia.com/TERM/v/virus.html

http://en.wikipedia.org/wiki/Computer_virus


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

http://www.webopedia.com/TERM/w/worm.html

http://en.wikipedia.org/wiki/Computer_worm


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

http://en.wikipedia.org/wiki/Logic_bomb

http://www.webopedia.com/TERM/T/Trojan_horse.html

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


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.

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

File1[R]File2 [RW]

File3[R]File4[RWX] Printer1[W]File5[RW]

File6[RWX] Plotter2[W]

Domain 1 Domain 2 Domain 3

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

n

Object

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

1 Read Read

Write

2 Read

Read

Write

Execute

Read

Write

Write

3

Read

Write

Execut

e

Write Write

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

n

Object

File

1

File

2

File

3

File

4

File

5

File

6

Printe

r

1

Plotte

r 2

D1 D2 D3

1 R R

W

Enter

2 R

R

W

X

R

W

W

3

R

W

X

W W

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

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).

O File R-- Pointer to File31 File RWX Pointer to File42 File RW- Pointer to File53 Printer -W- Pointer to Printer1

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

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.

Compiler Mailbox7 SecretEric Read

ExecuteHenry Read

Execute

Read

WriteRobert Read

Execute

Read Read

Write

Compiler Mailbox7 SecretEric Read

ExecuteHenry Read

Execute

Read

WriteRobert Read

Execute

Read

Write

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

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

Kernel Kernel

ServerEncapsulated serverCollaborator

27

CovertChannel


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).

-rw-------

a file that only the owner can read and write - no-one else

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 userg groupo othera allr readw 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 RKey +3 +3 +3 +3 +3 +3 +3Ciphertext Y R B D J H UTransposition 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 O Y A G E RO V A Y E G R

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: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

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:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

B B C D E F G H I J K L M N O P Q R S T U V W X Y Z A

C C D E F G H I J K L M N O P Q R S T U V W X Y Z A B

D D E F G H I J K L M N O P Q R S T U V W X Y Z A B C

E E F G H I J K L M N O P Q R S T U V W X Y Z A B C D

F F G H I J K L M N O P Q R S T U V W X Y Z A B C D E

G G H I J K L M N O P Q R S T U V W X Y Z A B C D E F

H H I J K L M N O P Q R S T U V W X Y Z A B C D E F G

I I J K L M N O P Q R S T U V W X Y Z A B C D E F G H

J J K L M N O P Q R S T U V W X Y Z A B C D E F G H I

K K L M N O P Q R S T U V W X Y Z A B C D E F G H I J

L L M N O P Q R S T U V W X Y Z A B C D E F G H I J K

M M N O P Q R S T U V W X Y Z A B C D E F G H I J K L

N N O P Q R S T U V W X Y Z A B C D E F G H I J K L M

O O P Q R S T U V W X Y Z A B C D E F G H I J K L M N

P P Q R S T U V W X Y Z A B C D E F G H I J K L M N O

Q Q R S T U V W X Y Z A B C D E F G H I J K L M N O P

R R S T U V W X Y Z A B C D E F G H I J K L M N O P Q

S S T U V W X Y Z A B C D E F G H I J K L M N O P Q R

T T U V W X Y Z A B C D E F G H I J K L M N O P Q R S

U U V W X Y Z A B C D E F G H I J K L M N O P Q R S T

50


V V W X Y Z A B C D E F G H I J K L M N O P Q R S T U

W W X Y Z A B C D E F G H I J K L M N O P Q R S T U V

X X Y Z A B C D E F G H I J K L M N O P Q R S T U V W

Y Y Z A B C D E F G H I J K L M N O P Q R S T U V W X

Z Z A B C D E F G H I J K L M N O P Q R S T U V W X Y

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

Li = 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

Ri − 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 1Bit 0 1 2 3 4 5 61 57 49 41 33 25 17 98 1 58 50 42 34 26 1815 10 2 59 51 43 35 2722 19 11 3 60 52 44 3629 63 55 47 39 31 23 1536 7 62 54 46 38 30 2243 14 6 61 53 45 37 2950 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 TableRound Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16Number of bits to 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1

56


rotatePC-2: Permuted Choice 2Bit 0 1 2 3 4 51 14 17 11 24 1 57 3 28 15 6 21 1013 23 19 12 4 26 819 16 7 27 20 13 225 41 52 31 37 47 5531 30 40 51 45 33 4837 44 49 39 56 34 5343 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 PermutationBit 0 1 2 3 4 5 6 71 58 50 42 34 26 18 10 29 60 52 44 36 28 20 12 417 62 54 46 38 30 22 14 625 64 56 48 40 32 24 16 833 57 49 41 33 25 17 9 141 59 51 43 35 27 19 11 349 61 53 45 37 29 21 13 557 63 55 47 39 31 23 15 7

IP^(-1): Inverse Initial PermutationBit 0 1 2 3 4 5 6 71 40 8 48 16 56 24 64 329 39 7 47 15 55 23 63 3117 38 6 46 14 54 22 62 3025 37 5 45 13 53 21 61 2933 36 4 44 12 52 20 60 2841 35 3 43 11 51 19 59 2749 34 2 42 10 50 18 58 2657 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 TableBit 0 1 2 3 4 51 32 1 2 3 4 57 4 5 6 7 8 913 8 9 10 11 12 1319 12 13 14 15 16 1725 16 17 18 19 20 2131 20 21 22 23 24 2537 24 25 26 27 28 2943 28 29 30 31 32 1

P PermutationBit 0 1 2 31 16 7 20 215 29 12 28 179 1 15 23 2613 5 18 31 1017 2 8 24 1421 32 27 3 925 19 13 30 629 22 11 4 25

59


S-Box 1: Substitution Box 1Row /

Column

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

0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 71 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 82 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 03 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13

S-Box 2: Substitution Box 2Row /

Column

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

0 15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 101 3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 52 0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 153 13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9S-Box 3: Substitution Box 3Row /

Column

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

0 10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 81 13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 12 13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 73 1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12S-Box 4: Substitution Box 4Row / Column 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 150 7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 151 13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 92 10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 43 3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14S-Box 5: Substitution Box 5Row /

Column

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

0 2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 91 14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 62 4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 143 11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3S-Box 6: Substitution Box 6Row /

Column

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

0 12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 111 10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 82 9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 63 4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13S-Box 7: Substitution Box 7Row / 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

60


Column0 4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 11 13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 62 1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 23 6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12S-Box 8: Substitution Box 8Row /

Column

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

0 13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 71 1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 22 7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 83 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 AdvantagesDES 64 bits 64 bits 56 bits 16 Simple and fast

Less mathematical

calculations

Cryptanalysis is

difficult3DES 64 bits 64 bits 168 bits 48 DES

rounds

More reliable

Easy to upgrade the

software to 3DES

Longer keylength,

difficult to crytanalyseAES 128 bits 128 bits 128/192/

256 bits

10/12/14

resp.

Longer keylengths

supported

62


More flexibleBlowfish 64 bits 64 bits 32-448

bits

16 Fast and secure

CompactRC5 32/64/128

bits

32/64/128

bits

0-2040

bits

variable Simple and fast

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 =

3233

- modulus (to be made public)

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 lowdata block length 64 bits minimum 512 bits key length 56 bits minimum 512 bits use of data space full, 64 bits (264), 8

bytes

variable, limited, not

defined, ciphering & deciphering

key

same different

ciphering & deciphering

algorithm

different same

algorithm contains only

XOR and branching

no no

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

(from Netscape

Corp.)

First SSL protocol for which implementations exists

SSL v3.0 Expired Internet

Draft (from

Netscape Corp.)

Revisions to prevent specific security attacks, add non-

RSA ciphers, and support for certificate chains

TLS v1.0 Proposed Internet

Standard (from

IETF)

Revision of SSL 3.0 to update the MAC layer to

HMAC, add block padding for block ciphers, message

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

handshake

protocol

SSL change

cipher spec

protocol

SSL alert

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

CLASS

EXPLANATION AND

CONSEQUENCES

JAVA

DEFENSE

System

Modification

The most severe class of attacks.

Applets that implement such attacks

are attack applets. Consequences of

these attacks: severe.

Strong

Invasion of

Privacy

If you value your privacy, this attack

class may be particularly odious. They

are implemented by malicious applets.

Include mail forging. Consequences

Strong

96


of these attacks: moderate.

Denial of

Service

Also serious but not severely so, these

attacks can bring a machine to a

standstill. Also implemented by

malicious applets. May require reboot.

Consequences of these attacks:

moderate.

Weak

Antagonism

Merely annoying, this attack class is

the most commonly encountered.

Implemented by malicious applets.

May require restart of browser.

Consequences of these attacks: light

to moderate.

Weak

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 TCSmith U

Brown C

40000

C

80000 S

Fair S

Good C

S

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.


Brown C

40000

C

Fair S

Good C

S

S

108


80000 S

Fig (2)

Case 2: A user with security clearance C would see the relation as:


Brown C

40000

C

80000

C

null C

Good C

C

C

Fig (3)

Case 3: A user with security clearance U would see the relation as:

Name Salary Job Performance TC

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:


Smith U

Brown C

40000

C

40000

C

80000 S

Fair S

Excellent C

Good C

S

C

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

Documents

security security

computer security

network security

information disclosure

unauthorized information

examples of security

computer use

various security services