is questions with answers(1-18)
TRANSCRIPT
1
Vignan’s Engineering College :: Vadlamudi
Department of CSE
Question Bank
III B.Tech (A) Sub : IS
UNIT I
1) (i) Explain the differences between passive attacks and massiveattacks?
(ii) Explain the various Security Services
(iii) Define Masquerader
2) (i) Explain man-in-the-middle attacks
(ii) Explain TCP Session Hijacking and UPD Session Hijacking
3) (i) Briefly explain about OSI security architecture
(ii) Explain about Internet Standards and RFCs
UNIT II
4) (i) Draw the general structure of DES and explain the encryptiondecryption process.
(ii) Mention the strengths and weakness of DES algorithm.
5) Describe the block cipher modes of operation in detail.
6) Explain how encryption and decryption are done using RSA cryptosystem
7) Users A and B use the Diffie Hellman key exchange technique acommon prime q=11 and a primitive root alpha=7.
(i) If user A has private key XA =3 what is A’s public key YA?
2
(ii) If user B has private key XB =6 what is B’s public key YB?
(ii) What is the shared secret key? Also write the algorithm.
(iv) How man in middle attack can be performed in Diffie Hellmanalgorithm
8) How does SHA-1 logic produce message digest?
9) Consider a Diffe Helmann scheme with a common prime q=11 andprimitive root a=2a) show that 2 is a primitive root of 11
b) If user A has public key YA=9, what is the primitive key XA?
c) If user B has public key YB=3 what is the shared secret key K?
10) Discuss about the objectives of HMAC and its features.
UNIT III
11) Describe Kerberos Version 5 protocol
12) (i) Describe the authentication dialogue used by Kerberos forobtaining required services.(ii) Explain the format of the X.509 certificate.
13) Describe the Kerberos Version 4 protocol and Version 5 protocolauthentication dialogue with technical deficiencies.
14) Explain about Kerberos
15) (i) Define Kerberos.
(ii) In the content of Kerberos, what is realm?
(iii) Assume the client C wants to communicate server S usingKerberos procedure.
How can it be achieved?
3
UNIT IV
16) How does PGP provide confidentiality and authentication servicefor e-mail and file
Storage applications? Draw the block diagram and explain itscomponents.
17) Explain the content types of MIME
18) Describe how PGP provides confidentiality and authenticationservice for e-mail applications.
19) Summarize the S/MIME capability.
20) (i) What are the services provided by PGP services
(ii) Explain the reasons for using PGP?
(iii) Why E-mail compatibility function in PGP needed?
(iv) Name any cryptographic keys used in PGP?
(v) Define key Identifier?
4
ANSWERS PREPARED BY IIICSE A STUDENTS
1) (i) Explain the differences between passive attacks andactive attacks?(ii) Explain the various Security Services(iii) Define Masquerader
Ans :-) i) In both X.800 and RFC 2828, attacks are classifiedinto passive attacks and active attacks.
PASSIVE
ATTACKS
ACTIVE ATTACKS
1. A passive attack
attempts to lean or make
use of information from the
system but does not affect
system resources.
1. An active attack attempts to alter
system resources or affect their
operation.
2. Passive attacks are in
the nature of
eavesdropping on, or
monitoring of,
transmissions.
2. Active attacks involve some
modification of the data stream or the
creation of a false stream.
3.There are two types of
passive attacks
3.There are four types of active
attacks
5
i. Release of message
contents
ii. Traffic analysis.
i. Masquerade
ii. Replay
iii. Modification
iv. Denial of services
4. Passive attacks are very
difficult to detect because
they do not involve any
alteration of the data.
4. They can be identified after some
observation.
5. Methods like
ENCRYPTION can prevent
these types of attacks.
5. It is very difficult to prevent these
attacks, as it requires physical
protection of all communications
facilities and paths at all times.
6. The emphasis in dealing
with passive attacks is on
prevention rather than
detection
6. Its goal is to detect attacks and to
recover from any disruption or delays
caused by them. Because the
detection has a deterrent effect, it
may also contribute to prevention.
ii). Security Services:-
X.800 defines a security service as a service provided by a
protocol layer of communicating open systems, which ensures
adequate security of the systems or of data transfers. X.800
6
divides these services into five categories and fourteen specific
services
Authentication:The authentication service is concerned with assuring that a
communication is authentic. In the case of a single message,
such as a 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.
i) 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.
ii) 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
purposes of unauthorized transmission or reception.
Two specific authentication services are defined in the standard.
Peer entity authentication:
Provides for the corroboration of the identity of a peer entity in
an association. It is provided for use at the establishment of, or
at times during the data transfer phase of, a connection. It
7
attempts to provide confidence that an entity is not performing
either a masquerade or an
Unauthorized replay of a previous connection.
Data origin authentication:
Provides for the corroboration of the source of a data unit. It
does not provide protection against the duplication or
modification of data units. This type of service supports
applications like electronic mail where there are no prior
interactions between the communicating entities.
Access Control:
In the context of network security, access control is the
ability to limit and control the access to host systems and
applications via communications links. To achieve this, each
entity trying to gain access must first be identified, or
authenticated, so that access rights can be tailored to the
individual.
Data Confidentiality:
Confidentiality is the protection of transmitted data from
passive attacks. The broadest service protects all user data
transmitted between two users over a period. For example, when
8
a TCP connection is set up between two systems, this broad
protection prevents the release of any user data transmitted over
the TCP connection.
Narrower forms of this service can also be defined,
including the protection of a single message or even specific
fields within a message. These refinements are less useful than
the broad approach and may even be more complex and
expensive to implement.
The other aspect of confidentiality is the protection of traffic
flow from analysis. This requires that an attacker not be able to
observe the source and destination, frequency, length, or other
characteristics of the traffic on a communications facility.
Data Integrity:
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
replays. 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 connectionless integrity service, one that deals with
individual messages only without regard to any larger context,
generally provides protection against message modification only.
9
The integrity service relates to active attacks, we are
concerned with detection rather than prevention. If a violation of
integrity is detected, then the service may simply report this
violation, and some other portion of software or human
intervention is required to recover from the violation. Alternatively,
there are mechanisms available to recover from the loss of
integrity of data, as we will review subsequently. The
incorporation of automated recovery mechanisms is, in general,
the more attractive alternative.
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
alleged sender in fact sent the message. Similarly, when a
message is received, the sender can prove that the alleged
receiver in fact received the message.
Availability Service:
Both X.800 and RFC 2828 define availability to be the property
of a system or a system resource being accessible and usable
upon demand by an authorized system entity, according to
10
performance specifications for the system (i.e., a system is
available if it provides services according to the system design
whenever users request them). A variety of attacks can result in
the loss of or 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.
X.800 treats availability as a property to be associated with
various security services. However, it makes sense to call out
specifically an availability service. An availability service is one
that protects a system to ensure its availability. This service
addresses the security concerns raised by denial-of-service
attacks. It depends on proper management and control of system
resources and thus depends on access control service and other
security services.
iii) Masquerade:Active attacks involve some modification of the data
stream or the creation of a false stream and can be subdivided
into four categories: masquerade, replay, modification of
messages, and denial of service.
11
A masquerade takes place when one entity pretends to
be a different entity. A masquerade attack usually inc1udes one of
the other forms of active attack. For example, authentication
sequences can be captured and replayed after a valid
authentication sequence has taken place, thus enabling an
authorized entity with few privileges to obtain extra privileges by
impersonating an entity that has those privileges.
Masquerade
HACKER
Internet or othercommsfafffffcility
USER RECEIVER
12
2. (i) Explain man-in-the-middle attacks(ii) Explain TCP session Hijacking and UPD Session
Hijacking
Ans :-)i)man-in-the-middle attacks:-
Suppose Sharuk and Amir wish to exchange keys, and Salman
is the adversary. The attack proceeds as follows:
1. Salman prepares for the attack by generating two random
private keys XD1 and XD2 and then computing the
corresponding public keys YD1 and YD2.
2. Sharuk transmits YA to Amir.
3. Salman intercepts YA and transmits YD1 to Amir. Salman
also calculates K2 = (YA) XD2 mod q.
4. Amir receives YD1 and calculates K1 = (YD1) XE mod q.
5. Amir transmits XA to Sharuk.
6. Salman intercepts XA and transmits YD2 to Sharuk. Salman
calculates K1 = (YB) XD1 mod q.
7. Sharuk receives YD2 and calculates K2 = (YD2) XA mod q.
At this point, Amir and Sharuk think that they share a
secret key, but instead Amir and Salman share secret key K1 and
Sharuk and Salman share secret key K2. All future
13
communication between Amir and Sharuk is compromised in the
following way:
1. Sharuk sends an encrypted message M: E(K2, M).
2. Salman intercepts the encrypted message and decrypts it,
to recover M.
3. Salman sends Amir E(K1, M) or E(K1, M'), where M' is
any message. In the first case, Salman simply wants to
eavesdrop on the communication without altering it. In the
second case, Salman wants to modify the message going to
Amir.
The key exchange protocol is vulnerable to such an attack
because it does not authenticate the participants. This
vulnerability can be overcome with the use of digital signatures
and public-key certificates.
-------------------------------------------------------------------------------------
3) (i) Briefly explain about OSI security architecture(ii) Explain about Internet Standards and RFCsThe OSI Security Architecture:
To assess effectively the security needs of an organization and toevaluate and choose various security products and policies, themanager responsible for security needs some systematic way ofdefining the requirements for security and characterizing theapproaches to satisfying those requirements. This is difficultenough in a centralized data processing environment; with the
14
use of local and wide area networks, the problems arecompounded.
ITU-T Recommendation X.800, Security Architecture for OSI,defines such a systematic approach. The OSI securityarchitecture is useful to managers as a way of organizing the taskof providing security. Furthermore, because this architecture wasdeveloped as an international standard, computer andcommunications vendors have developed security features fortheir products and services that relate to this structured definitionof services and mechanisms.
The OSI security architecture was developed in the context of theOSI protocol architecture. The OSI security architecture focuseson security attacks, mechanisms, and services. These can bedefined briefly as follows:
Security attack: Any action that compromises the security ofinformation owned by an organization.
Security mechanism: A process (or a device incorporatingsuch a process) that is designed to detect, prevent, orrecover from a security attack.
Security service: A processing or communication service thatenhances the security of the data processing systems andthe information transfers of an organization. The services areintended to counter security attacks, and they make use ofone or more security mechanisms to provide the service.
15
INTERNETSTANDARDSANDRFC’S:
INTERNET SOCIETY:
By universal agreement, an organization known as the InternetSociety is responsible for the development and publication ofthese standards .The Internet Society is the coordinatingcommittee for Internet design, engineering, and management.Three organizations under the Internet Society are responsible forthe actual work of standards development and publication.
Internet Architecture Board (IAB): Responsible for definingthe overall architecture of the Internet, providing guidanceand broad direction to the IETF.
Internet Engineering Task Force (IETF): The protocolengineering and development arm of the Internet.
Internet Engineering Steering Group (IESG): Responsiblefor technical management of IETF activities and theInternet standards process.
RFC Publication:
Working groups chartered by the IETF carry out the actualdevelopment of new standards and protocols for the Internet.
Membership in a working group is voluntary; any interested partymay participate. During the development of a specification, aworking group will make a draft version of the document availableas an Internet Draft, which is placed in the IETF’s "Internet Drafts"online directory.
The document may remain as an Internet Draft for up to sixmonths, and interested parties may review and comment on the
16
draft. During that time, the IESG may approve publication of thedraft as an RFC (Request for Comment).
If the draft has not progressed to the status of an RFC during thesix-month period, it is withdrawn from the directory. The workinggroup may subsequently publish a revised version of the draft.
The IETF is responsible for publishing the RFC’s, with approval ofthe IESG. The RFC’s are the working notes of the Internetresearch and development community. A document in this seriesmay be on essentially any topic related to computercommunications and may be anything from a meeting report tothe specification of a standard.
The Standardization Process:
The decision of which RFC’s become Internet standards is madeby the IESG, on the recommendation of the IETF. To become astandard, a specification must meet the following criteria:
Be stable and well understood Be technically competent Have multiple, independent, and interoperable
implementations with substantial operational experience Enjoy significant public support Be recognizably useful in some or all parts of the Internet
The key difference between these criteria and those used forinternational standards from ITU is the importance here onoperational experience.
Figure: Internet RFC Publication Process
17
Figure shows the series of steps, called the standards track, thata specification goes through to become a standard; this processis defined in RFC 2026.
The steps involve increasing amounts of scrutiny and testing. Ateach step, the IETF must make a recommendation foradvancement of the protocol, and the IESG must ratify it. Theprocess begins when the IESG approves the publication of anInternet Draft document as an RFC with the status of ProposedStandard.
The white boxes in the diagram represent temporary states, whichshould be occupied for the minimum practical time. However, adocument must remain a Proposed Standard for at least six
18
months and a Draft Standard for at least four months to allow timefor review and comment. The gray boxes represent long-termstates that may be occupied for years.
For a specification to be advanced to Draft Standard status theremust be at least two independent and interoperableimplementations from which adequate operational experience hasbeen obtained.
After significant implementation and operational experience hasbeen obtained, a specification may be elevated to InternetStandard.
At this point, the Specification is assigned an STD number as wellas an RFC number.
Finally, when a protocol becomes obsolete, it is assigned to theHistoric state
--------------------------------------------------------------------------------------
4) (i) Draw the general structure of DES and explain theencryption decryption process.
(ii) Mention the strengths and weakness of DES algorithm.
Data Encryption Algorithm:
The most widely used encryption scheme isdefined in data encryption standard (DES) adopted in 1977 bythe NIST (national institute of standards and technology).Thealgorithm it self is referred as Data Encryption Algorithm (DEA).
19
It uses 64 bit block of data and 56 bit length of key used as inputand produces 64 bit block of cipher text. The overall scheme forDES illustrated in the following figure.
Figure: General Depiction of DES Encryption Algorithm
20
The left hand side of figure shows that the processing of plain textproceeds in three phases.
1) First 64 bit plain text is passed through an initial permutation(IP) that rearranges bits toproduce permuted input.
2) This followed by a phase consisting of 16 iterations of samefunction. The output of last iteration consists of 64 bits that are afunction of the input plain text and key.
The left and right halves of data are swapped to produce preoutput.
3) Finally the pre output is passed through inverse permutationfunction to produce 64 bit cipher text.
The right hand portion of above figure shows the way in which 56bit key is used.
Initially, the key is passed through a permutation function. Thenfor each of the 16 iterations, a sub key is produced by thecombination of a left circular shift and a permutation. Thepermutation function is the same foreach iteration, but a differentsub key is produced because of the repeated shifting of the keybits.
Figure: Single Round of DES Algorithm
21
The above figure examines how each round of operationperformed.
The 64-bit permuted input is divided in to left and right halves.These are treated as separate 32-bit quantities, labeled L (left)and R (right).
The general formula for each round is
Li = Ri-1
RI = Li-1 X OR F (Ri-1, Ki)
Thus, the left-hand output of iteration (Li) is simply equal to theright-hand input to that iteration (Ri-1).
22
The right-hand output (Ri-) is the exclusive-OR of Li-1, and acomplex function F of Ri-1 and sub key k. This complex functioninvolves both permutation and substitution operations.
The substitution operation, represented as tables called S- boxes,simply maps each combination of 48 input bits into a particular32-bit pattern.
The 56 bit key is then treated as two 28-bit blocks, labeled C0, D0.C and D are separately subjected to a circular left shift, orrotation, of 1 or 2 bits. These shifted values serves as input to thenext iteration and to another permutation function which produces48- bit output that serves as input to the function F (Ri-1, Ki).
DECRYPTION USING DES:
The process of decryption is essentially same asencryption process. The rule is as follows.
Use the cipher text as input to the DES algorithm, butuses the keys in reverse order. That is K16 for firstiteration, K14 for second iteration and so on until K1 isused on the last iteration.
STRENGTH OF DES:
1) Concerns about algorithm itself: over the years numerousefforts are made to find and exploit weaknesses in thealgorithm, making DES most studied encryption algorithmin existence. Despite of numerous approaches, no onehas so far succeeded in discovering a fatal weakness inDES.
23
2) Use of 56 – bit key: With a key length of 56 bits, there are256 possible keys, which are approximately 7. 2 x 1016.Thus, on the face of it, a brute-force attack appearsimpractical. Assuming that, on average, half the key spacehas to be searched, a single machine performing oneDES encryption per microsecond would take more than athousand years to break the cipher.
DES finally and definitively proved insecure in July 1998, whenthe Electronic Frontier Foundation (EFF) announced that it hadbroken a DES encryption using a special-purpose "DES cracker"machine that was built for less than $250,000. The attack tookless than three days.
Finally key length of 128 bit is optimal for the algorithms.
WEAKNESS:
1) DEA was designed for mid 70s hardware implementationand does not produce efficient software code.
2) DEA uses a 64 bit block size. For reasons of bothefficiency and security, a larger block size is desirable.
3) Encryption or Decryption process is relatively slowbecause of key length and number of rounds.
24
5) Describe the block cipher modes of operation in detail.
Ans:-) A block cipher algorithm is a basic building block for
providing data security. To apply a block cipher in a variety of
applications, four "modes of operation" have been defined by
NIST.
In essence, a “mode of operation” is a technique for enhancing
the effect of a cryptographic algorithm or adapting the algorithm
for an application, such as applying a lock cipher to a sequence
of data blocks or a data stream. The four modes are intended to
cover virtually all the possible applications of encryption for which
a block cipher could be used. As new applications and
requirements have appeared, NIST has expanded the list of
recommended modes to five in Special Publication 800-38A.
These modes are intended for use with any symmetric block
cipher, including triple DES and AES.
Electronic Codebook Mode
The simplest mode is the electronic codebook (ECB) mode, in
which plaintext is handled one block at a time and each block of
plaintext is encrypted using the same key (Figure 6.3). The term
codebook is used because, for a given key, there is a unique
cipher text for every b –bit block of plaintext. Therefore, we can
imagine a gigantic codebook in which there is an entry for every
possible b-bit plaintext pattern showing its corresponding cipher
text.
25
Figure 6.3. Electronic Codebook (ECB) Mode
For a message longer than b bits, the procedure is simply to
break the message into b-bit blocks, padding the last block if
necessary. Decryption is performed one block at a time, always
using the same key. In Figure 6.3, the plaintext (padded as
necessary) consists of a sequence of b-bit blocks, P1, P2,..., PN;
the corresponding sequence of ciphertext blocks is C1, C2,..., CN.
26
The ECB method is ideal for a short amount of data, such as an
encryption key. Thus, if you want to transmit a DES key securely,
ECB is the appropriate mode to use.
The most significant characteristic of ECB is that the same b-bit
block of plaintext, if it appears more than once in the message,
always produces the same ciphertext.
For lengthy messages, the ECB mode may not be secure. If the
message is highly structured, it may be possible for a cryptanalyst
to exploit these regularities. For example, if it is known that the
message always starts out with certain predefined fields, then the
cryptanalyst may have a number of known plaintext-ciphertext
pairs to work with. If the message has repetitive elements, with a
period of repetition a multiple of b bits, then these elements can
be identified by the analyst. This may help in the analysis or may
provide an opportunity for substituting or rearranging blocks.
Cipher Block Chaining Mode
To overcome the security deficiencies of ECB, we would like a
technique in which the same plaintext block, if repeated, produces
different ciphertext blocks. A simple way to satisfy this
requirement is the cipher block chaining (CBC) mode (Figure 6.4).
In this scheme, the input to the encryption algorithm is the XOR of
the current plaintext block and the preceding ciphertext block; the
same key is used for each block. In effect, we have chained
27
together the processing of the sequence of plaintext blocks. The
input to the encryption function for each plaintext block bears no
fixed relationship to the plaintext block. Therefore, repeating
patterns of b bits are not exposed
Figure 6.4. Cipher Block Chaining (CBC) Mode
28
For decryption, each cipher block is passed through the
decryption algorithm. The result is XORed with the preceding
cipher text block to produce the plaintext block. To see that this
works, we can write
Cj = E(K, [Cj-1 Pj])
Then
D(K, Cj) = D(K, E(K, [Cj-1 Pj]))
D(K, Cj) = Cj-1 Pj
Cj-1 D(K, Cj) = Cj-1 Cj- 1 Pj = Pj
To produce the first block of cipher text, an initialization vector (IV)
is XORed with the first block of plaintext. On decryption, the IV is
XORed with the output of the decryption algorithm to recover the
first block of plaintext. The IV is a data block that is that same size
as the
cipher block.
The IV must be known to both the sender and receiver but be
unpredictable by a third party. For maximum security, the IV
should be protected against unauthorized changes. This could be
done by sending the IV using ECB encryption. One reason for
29
protecting the IV is as follows: If an opponent is able to fool the
receiver into using a different value for IV, then the opponent is
able to invert selected bits in the first block of plaintext. To see
this, consider the following:
C1 = E(K, [IV P1])
P1 = IV D(K, C1)
Now use the notation that X[i] denotes the ith bit of the b-bit
quantity X. Then
P1[i] = IV[i] D(K, C1)[i]
Then, using the properties of XOR, we can state
P1[i]' = IV[i]' D(K, C1)[i]
where the prime notation denotes bit complementation. This
means that if an opponent can predictably change bits in IV, the
corresponding bits of the received value of P1 can be changed.
For other possible attacks based on knowledge of IV, see
[VOYD83].
In conclusion, because of the chaining mechanism of CBC, it is
an appropriate mode for encrypting messages of length greater
than b bits.
In addition to its use to achieve confidentiality, the CBC mode can
be used for authentication. This use is described in Part Two.
30
Cipher Feedback
The DES scheme is essentially a block cipher technique that uses
b-bit blocks. However, it is possible to convert DES into a stream
cipher,
using either the cipher feedback (CFB) or the output feedback
mode. A stream cipher eliminates the need to pad a message to
be an integral number of blocks. It also can operate in real time.
Thus, if a character stream is being transmitted, each character
can be encrypted and transmitted immediately using a character-
oriented stream cipher.
One desirable property of a stream cipher is that the ciphertext be
of the same length as the plaintext. Thus, if 8-bit characters are
being transmitted, each character should be encrypted to produce
a cipher text output of 8 bits. If more than 8 bits are produced,
transmission
capacity is wasted.
Figure 6.5 depicts the CFB scheme. In the figure, it is assumed
that the unit of transmission iss bits; a common value is s = 8. As
with CBC,
the units of plaintext are chained together, so that the ciphertext
of any plaintext unit is a function of all the preceding plaintext. In
this case, rather than units of b bits, the plaintext is divided into
segments of s bits.
31
Figure 6.5. s-bit Cipher Feedback (CFB) Mode
First, consider encryption. The input to the encryption function is a
b-bit shift register that is initially set to some initialization vector
(IV).
The leftmost (most significant) s bits of the output of the
encryption function are XORed with the first segment of plaintextP
1 to produce the first unit of ciphertext C1, which is then
transmitted. In addition, the contents of the shift register are
32
shifted left bys bits and C1 is placed in the rightmost (least
significant) s bits of the shift register. This process continues until
all plaintext units have been encrypted.
For decryption, the same scheme is used, except that the
received ciphertext unit is XORed with the output of the
encryption function to produce the plaintext unit. Note that it is the
encryption function that is used, not the decryption function. This
is easily explained. LeSt s(X)
be defined as the most significant s bits of X. Then
C1 = P1 Ss[E(K, IV)]
Therefore,
P1 = C1 Ss[E(K, IV)]
The same reasoning holds for subsequent steps in the process.
Output Feedback Mode
The output feedback (OFB) mode is similar in structure to that of
CFB, as illustrated in Figure 6.6. As can be seen, it is the output
of the encryption function that is fed back to the shift register in
OFB, whereas in CFB the ciphertext unit is fed back to the shift
register
33
Figure 6.6. s-bit Output Feedback (OFB) Mode
One advantage of the OFB method is that bit errors in
transmission do not propagate. For example, if a bit error occurs
iCn1 only the recovered value of is P1 affected; subsequent
plaintext units are not corrupted. With CFB, C1 also serves as
input to the shift register and therefore causes additional
corruption downstream.
34
The disadvantage of OFB is that it is more vulnerable to a
message stream modification attack than is CFB. Consider that
complementing a bit in the ciphertext complements the
corresponding bit in the recovered plaintext. Thus, controlled
changes to the recovered plaintext
can be made. This may make it possible for an opponent, by
making the necessary changes to the checksum portion of the
message as well as to the data portion, to alter the ciphertext in
such a way that it is not detected by an error-correcting code. For
a further discussion,
Counter Mode
Although interest in the counter mode (CTR) has increased
recently, with applications to ATM (asynchronous transfer mode)
network security and IPSec (IP security), this mode was proposed
early on (e.g., [DIFF79]).
Figure 6.7 depicts the CTR mode. A counter, equal to the
plaintext block size is used. The only requirement stated in SP
800-38A is that the counter value must be different for each
plaintext block that is encrypted. Typically, the counter is
initialized to some value and then
35
incremented by 1 for each subsequent block (modulo 2 b where b
is the block size). For encryption, the counter is encrypted and
then
XORed with the plaintext block to produce the ciphertext block;
there is no chaining. For decryption, the same sequence of
counter values is used, with each encrypted counter XORed with
a ciphertext block to recover the corresponding plaintext block.
Figure 6.7. Counter (CTR) Mode
36
lists the following advantages of CTR mode:
Hardware efficiency: Unlike the three chaining modes,
encryption (or decryption) in CTR mode can be done in parallel on
multiple blocks of plaintext or ciphertext. For the chaining modes,
the algorithm must complete the computation on one block before
beginning on the next block. This limits the maximum throughput
of the algorithm to the reciprocal of the time for one execution of
block encryption or decryption. In CTR mode, the throughput is
only limited by the amount of parallelism that is achieved.
Software efficiency: Similarly, because of the opportunities for
parallel execution in CTR mode, processors that support parallel
features, such as aggressive pipelining, multiple instruction
dispatch per clock cycle, a large number of registers, and SIMD
instructions, can be effectively utilized.
Preprocessing: The execution of the underlying encryption
algorithm does not depend on input of the plaintext or ciphertext.
Therefore, if sufficient memory is available and security is
maintained, preprocessing can be used to prepare the output of
the
encryption boxes that feed into the XOR functions in Figure 6.7.
When the plaintext or ciphertext input is presented, then the only
37
computation is a series of XORs. Such a strategy greatly
enhances throughput.
Random access: The ith block of plaintext or ciphertext can be
processed in random-access fashion. With the chaining modes,
block Ci cannot be computed until the i - 1 prior block are
computed. There may be applications in which a ciphertext is
stored and it is desired to decrypt just one block; for such
applications, the random access feature is attractive.
Provable security: It can be shown that CTR is at least as
secure as the other modes discussed in this section.
Simplicity: Unlike ECB and CBC modes, CTR mode requires
only the implementation of the encryption algorithm and not the
decryption algorithm. This matters most when the decryption
algorithm differs substantially from the encryption algorithm, as it
does for AES. In addition, the decryption key scheduling need not
be implemented.
---------------------------------------------------------------------------------------
6) Explain how encryption and decryption are done usingRSA crypto system
A)
The RSA Algorithm:-
38
The pioneering paper by Diffie and Hellman [DIFF76b] introduced
a new approach to cryptography and, in effect, challenged
cryptologists to come up with a cryptographic algorithm that met
the requirements for public-key systems. One of the first of the
responses to the
challenge was developed in 1977 by Ron Rivest, Adi Shamir, and
Len Adleman at MIT and first published in 1978
The Rivest-Shamir-Adleman (RSA) scheme has since that time
reigned supreme as the most widely accepted and implemented
general-purpose approach to public-key encryption.
[4] Apparently, the first workable public-key system for
encryption/decryption was put forward by Clifford Cocks of
Britain's CESG in 1973 [COCK73]; Cocks's method is virtually
identical to RSA.
The RSA scheme is a block cipher in which the plaintext and
ciphertext are integers between 0 and n 1 for some n. A typical
size for n is 1024 bits, or 309 decimal digits. That is, n is less than
2
. We examine RSA in this section in some detail, beginning with
an explanation of the algorithm. Then we examine some of the
computational and cryptanalytical implications of RSA.
Description of the Algorithm
39
7) Users A and B use the Diffie Hellman key exchange technique a
common prime q=11 and a primitive root alpha=7.
(i) If user A has private key XA =3 what is A’s public key YA?
(ii) If user B has private key XB =6 what is B’s public key YB?
(ii) What is the shared secret key? Also write the algorithm.
(iv) How man in middle attack can be performed in Diffie Hellman
algorithm
Ans)
i) Given that
Private Key XA=3
Public Key YA=7 power 3mod 11=
ii) Given that
Private Key XB=6
Public Key XB=7 power 6mod 11=
iii)SHARED SECRET KEY:
40
41
1. Darth prepares for the attack by generating two random private
keys XD1 and XD2 and then computing the corresponding public
keys YD1 and YD2.
2. Alice transmits YA to Bob.
3.Darth intercepts YA and transmits YD1 to Bob. Darth also
calculates K2 = (YA) XD2 mod q.
4.Bob receives YD1 and calculates K1 = (YD1)XE mod q.
5. Bob transmits XA to Alice.
6.Darth intercepts XA and transmits YD2 to Alice. Darth
calculates K1 = (YB) XD1 mod q
7.Alice receives YD2 and calculates K2 = (YD2) XA mod q.
At this point, Bob and Alice think that they share a secret key, but
instead Bob and Darth share secret key K1 and Alice and Darth
share secret key K2. All future communication between Bob and
Alice is compromised in the following way:
1. Alice sends an encrypted messageM : E(K2, M).
2. Darth intercepts the encrypted message and decrypts it, to
recoverM .
3.Darth sends Bob E(K1, M) or E(K1, M'), where M' is any
message. In the first case, Darth simply wants to eavesdrop on
the communication without altering it. In the second case, Darth
wants to modify the message going to Bob.
42
8) How does SHA-1 logic produce message digest?
Secure Hash Algorithm:
The Secure Hash Algorithm (SHA) was developed by the National
Institute of Standards and Technology (NIST) and published as a
federal information processing standard (FIPS 180) in 1993; a
revised version was issued as FIPS 180-1 in 1995 and is
generally referred to as SHA-1. The actual standards document is
entitled Secure Hash Standard. SHA is based on the hash
function MD4 and its design closely models MD4. SHA-1 is also
specified in RFC 3174, which essentially duplicates the material in
FIPS 180-1, but adds a C code implementation.
SHA-1 produces a hash value of 160 bits. In 2002, NIST
produced a revised version of the standard, FIPS 180-2, that
defined three new versions of SHA, with hash value lengths of
256, 384, and 512 bits, known as SHA-256, SHA-384, and SHA-
512 . These new versions have the same underlying structure and
use the same types of modular arithmetic and logical binary
operations as SHA-1.
SHA-512 Logic
The algorithm takes as input a message with a maximum length
of less than 2128 bits and produces as output a 512-bit message
digest.
43
Message Digest Generation Using SHA-512
The processing consists of the following steps:
Step 1: Append padding bits. The message is padded so that
its length is congruent to 896 modulo 1024 [length 896(mod
44
1024)]. Padding is always added, even if the message is already
of the desired length. Thus, the number of padding bits is in the
range of 1 to 1024. The padding consists of a single 1-bit followed
by the necessary number of 0-bits.
Step 2: Append length. A block of 128 bits is appended to the
message. This block is treated as an unsigned 128-bit integer
(most significant byte first) and contains the length of the original
message (before the padding). The outcome of the first two steps
yields a message that is an integer multiple of 1024 bits in length.
InF igure 12.1, the expanded message is represented as the
sequence of 1024-bit blocks M1, M2,..., MN, so that the total
length of the expanded message is N x 1024 bits.
Step 3: Initialize hash buffer. A 512-bit buffer is used to hold
intermediate and final results of the hash function. The buffer can
be represented as eight 64-bit registers (a, b, c, d, e, f, g, h).
These registers are initialized to the following 64-bit integers
(hexa decimal values):
a = 6A09E667F3BCC908
b = BB67AE8584CAA73B
c = 3C6EF372FE94F82B
c = A54FF53A5F1D36F1
e = 510E527FADE682D1
45
f = 9B05688C2B3E6C1F
g = 1F83D9ABFB41BD6B
h = 5BE0CDI9137E2179
These values are stored in big-endian format, which is the most
significant byte of a word in the low-address (leftmost) byte
position. These words were obtained by taking the first sixty-four
bits of the fractional parts of the square roots of the first eight
prime numbers.
Step 4: Process message in 1024-bit (128-word) blocks. The
heart of the algorithm is a module that consists of 80 rounds;
this module is labeled F in above figure. The logic is illustrated in
belowfigure.
SHA-512 Processing of a Single 1024-Bit Block
46
47
Each round takes as input the 512-bit buffer value abcdefgh, and
updates the contents of the buffer. At input to the first round, the
buffer has the value of the intermediate hash value, Hi-1. Each
round t makes use of a 64-bit value Wt derived from the current
1024-bit block being processed (Mi) These values are derived
using a message schedule described subsequently.
Each round also makes use of an additive constant Kt where 0 t
79 indicates one of the 80 rounds. These words represent the first
sixty-four bits of the fractional parts of the cube roots of the first
eighty prime numbers. The constants provide a "randomized" set
of 64-bit patterns, which should eliminate any regularities in the
input data. The output of the eightieth round is added to the input
to the first round (Hi-1)to produce Hi. The addition is done
independently
for each of the eight words in the buffer with each of the
corresponding words in Hi-1 using addition modulo 2 64.
Step 5: Output. After all N 1024-bit blocks have been processed,
the output from the Nth stage is the 512-bit message digest.
We can summarize the behavior of SHA-512 as follows:
48
H0 = IV
Hi = SUM64(Hi-1, abcdefghi)
MD = HN
where
IV = initial value of the abcdefgh buffer, defined in step 3
abcdefghi = the output of the last round of processing of the ith
message block
N = the number of blocks in the message (including padding and
length fields)
SUM64 = Addition modulo 2power64 performed separately on
each word of the pair of inputs
MD = final message digest value
SHA-512 Round Function
Let us look in more detail at the logic in each of the 80 steps of
the processing of one 512-bit block (Figure 12.3). Each round is
defined by the following set of equations:
49
Where
t =step number; 0 t 79
Ch(e, f, g) = (e AND f) (NOT e AND g) the conditional function:
If e then f else g
Maj(a, b, c) = (a AND b) (a AND c) (b AND c) the
function is true only of the majority
(two or three) of the arguments are true.
50
ROTR n
(x)= circular right shift (rotation) of the 64-bit argument x by n bits
Wt = a 64-bit word derived from the current 512-bit input block
Kt = a 64-bit additive constant
+= addition modulo 2power64
Elementary SHA-512 Operation (single round)
51
It remains to indicate how the 64-bit word values Wt are derived
from the 1024-bit message. Figure 12.4 illustrates the mapping.
The first 16 values of Wt are taken directly from the 16 words of
the current block. The remaining values are defined as follows:
Where
52
ROTR n power (x) = circular right shift (rotation) of the 64-bit
argument x by n bits
SHR n power (x) = left shift of the 64-bit argument x by n bits
with padding by zeros on the right
Figure 12.4. Creation of 80-word Input Sequence for SHA-512Processing of Single Block
Thus, in the first 16 steps of processing, the value of Wt is equal
to the corresponding word in the message block. For the
remaining 64 steps, the value of Wt consists of the circular left
53
shift by one bit of the XOR of four of the preceding values of Wt,
with two of those values subjected to shift and rotate operations.
This introduces a great deal of redundancy and interdependence
into the message blocks that are compressed, which complicates
the task of finding a different message block that maps to the
same compression function output.
---------------------------------------------------------------------------------------
9) Consider a Diffe Helmann scheme with a common primeq=11 and primitive root a=2a) show that 2 is a primitive root of 11b) If user A has public key YA=9, what is the primitive keyXA?c) If user B has public key YB=3 what is the shared secretkey K?
Ans:) consider a Diffe Helmann scheme with a common prime
q=11 and primitive root a=2
a) show that 2 is primitive root of 11
given that
q=11
a=2
to show that 2 is primitive root of 11 we need to find
a mod q, a2 mod q,a3 mod q,………..,aq-1 mod q
if all the values lies between 1 to q-1 then a is primitive of q
54
21 % 11 =2
22 % 11 =4%11=4
23 % 11 =8%11=8
24 % 11 =16%11 =5
25 % 11 =32%11 =10
26 % 11 =64%11 =9
27 % 11 =128%11 =7
28 % 11 =256%11 =3
29 % 11 =512%11 =6
210 % 11 =1024%11 =1
therefore all the values lies between 1 to 10
so 2 is primitive root of 11
b) if user A has public key YA=9,what is primitive key XA?
Given YA=9, a=2
By differ helmann key exchange algorithm
YA= (a)XA mod q
By trail and error method the value of XA which satisfies the YA=9
If XA=1, YA=21 % 11 =2
If XA=2, YA=22 % 11 =4%11=4
55
If XA=3, YA=23 % 11 =8%11=8
If XA=4, YA=24 % 11 =16%11 =5
If XA=5, YA=25 % 11 =32%11 =10
If XA=6, YA=26 % 11 =64%11 =9
Therefore for the value of XA=6 YA=9
Primitive key XA=6
(c) If user B has public YB=3 what is shared secret key K
we need to know the value of XB
XB can be found by trail and error same as XA
If XB=1, YB=21 % 11 =2
If XB=2, YB=22 % 11 =4%11=4
If XB=3, YB=23 % 11 =8%11=8
If XB=4, YB=24 % 11 =16%11 =5
If XB=5, YB=25 % 11 =32%11 =10
If XB=6, YB=26 % 11 =64%11 =9
If XB=7, YB=27 % 11 =128%11 =7
If XB=8, YB=28 % 11 =256%11 =3
Therefore XB=8
Shared secret key
56
K=(YB)XA mod q
K=(3)6 % 11
=729%11
=3
---------------------------------------------------------------------------------------
10) Discuss about the objectives of HMAC and its features?
A: HMAC(Hash message authentication code) has been issued
as RFC 2104,has been chosen as the mandatory-to-implement
mAC for IP security,and is used in other internet protocols, such
as transport layer security.
HMAC design objectives:
RFC 2104 lists the following design objectives for
HMAC:
To use,with out modifications,available hash functions.In
particular,hash functions that perform well in software,and for
which code is freely and widely available.
To allow for easy replaceability of the embedded hash
function in case faster or more secure hash functions are found or
required.
To preserve the original performance of hash function
without incurring a significant degradation
To use and handle keys in a simple way.
57
To have a well understood cryptographic analysis of the
strength of the authentication mechanism based on reasonable
assumptions on the embedded hash function.
The first two objectives are important to the
acceptability of HMAC.HMAC treats the hash Function as a
“black-box”. There are a lot of advantages by using HMAC, the
main advantage id if the security of embedded hash function is
compromised, the security of HMAC could be retained simply by
replacing the embedded hash function with a more secure one.
HMAC ALGORITHM:
Let:
H(·) be a cryptographic hash function
K be a secret key padded to the right with extra zeros to the
block size of the hash function
m be the message to be authenticated
|| denote concatenation
denote exclusive or (XOR)
opad be the outer padding (0x5c5c5c…5c5c, one-block-
long hexadecimal constant)
ipad be the inner padding (0x363636…3636, one-block-
long hexadecimal constant)
Then
HMAC(K,m) is mathematically defined by
58
HMAC(K,m) = H((K + || opad)|| H((K + ipad) || m)).
In words,1. Append zeros to the left end of K to create a b-bit string K +
2. XOR(bitwise exclusive or) K + with ipad to produce the b-bit
block Si
3. Append M to Si
4. append H to stream generated in step 3
5. XOR K + with opad to produce the b-bit block S0.
6. Append the hash result from step 4 to S0
7. Apply H to the stream generated in step 6 and output the
result.
---------------------------------------------------------------------------------------
11) Describe Kerberos version 5 protocol.
Ans)
Kerberos version 5 is specified in RFC 1510 and provides a
number of improvements over version 4.
The protocol is as below
The following is an intuitive description. The client authenticates
itself to the Authentication Server and receives a ticket. (All tickets
are time-stamped.) It then contacts the Ticket Granting Server,
and using the ticket it demonstrates its identity and asks for a
service. If the client is eligible for the service, then the Ticket
59
Granting Server sends another ticket to client. The client then
contacts the Service Server, and using this ticket it proves that it
has been approved to receive the service.
A simplified and more detailed description of the protocol follows.
The following abbreviations are used:
AS = Authentication Server
SS = Service Server
TGS = Ticket-Granting Server
TGT = Ticket-Granting Ticket
The client authenticates to the AS once using a long-term shared
secret (e.g. a password) and receives a TGT from the AS. Later,
when the client wants to contact some SS, it an (re)use this
ticket to get additional tickets for SS without resorting to using the
shared secret. These tickets can be used to prove authentication
to SS.
The phases are detailed below.
User Client-based Logon
1. A user enters a username and password on the client
machine.
2. The client performs a one-way function (hash usually) on the
entered password, and this becomes the secret key of the
client/user.
60
Client Authentication
1. The client sends a cleartext message of the user ID to the
AS requesting services on behalf of the user. (Note: Neither
the secret key nor the password is sent to the AS.) The AS
generates the secret key by hashing the password of the
user found at the database (e.g. Active Directory in Windows
Server).
2. The AS checks to see if the client is in its database. If it is,
the AS sends back the following two messages to the client:
Message A: Client/TGS Session Key encrypted using the
secret key of the client/user.
Message B: Ticket-Granting Ticket (which includes the
client ID, client network address, ticket validity period, and
the client/TGS session key) encrypted using the secret
key of the TGS.
3. Once the client receives messages A and B, it decrypts
message A to obtain the Client/TGS Session Key. This
session key is used for further communications with the
TGS. (Note: The client cannot decrypt Message B, as it is
encrypted using TGS's secret key.) At this point, the client
has enough information to authenticate itself to the TGS.
Client Service Authorization
1. When requesting services, the client sends the following two
messages to the TGS:
61
Message C: Composed of the TGT from message B and
the ID of the requested service.
Message D: Authenticator (which is composed of the
client ID and the timestamp), encrypted using
the Client/TGS Session Key.
2. Upon receiving messages C and D, the TGS retrieves
message B out of message C. It decrypts message B using
the TGS secret key. This gives it the "client/TGS session
key". Using this key, the TGS decrypts message D
(Authenticator) and sends the following two messages to the
client:
Message E: Client-to-server ticket (which includes the
client ID, client network address, validity period
and Client/Server Session Key) encrypted using the
service's secret key.
Message F: Client/server session key encrypted with
the Client/TGS Session Key.
Client Service Request
1. Upon receiving messages E and F from TGS, the client has
enough information to authenticate itself to the SS. The
client connects to the SS and sends the following two
messages:
Message E from the previous step (the client-to-server
ticket, encrypted using service's secret key).
62
Message G: a new Authenticator, which includes the
client ID, timestamp and is encrypted using client/server
session key.
2. The SS decrypts the ticket using its own secret key to
retrieve the Client/Server Session Key. Using the sessions
key, SS decrypts the Authenticator and sends the following
message to the client to confirm its true identity and
willingness to serve the client:
Message H: the timestamp found in client's Authenticator
plus 1, encrypted using the Client/Server Session Key.
3. The client decrypts the confirmation using the Client/Server
Session Key and checks whether the timestamp is correctly
updated. If so, then the client can trust the server and can
start issuing service requests to the server.
4. The server provides the requested services to the client.
(1) C AS Options||IDc||Realmc||IDtgs||Times||Nonce1
(2) AS C Realmc||IDC||Tickettgs||E(Kc,
[Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])
Tickettgs = E(Ktgs,
[Flags||Kc,tgs||Realmc||IDc||ADc||Times])
63
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C TGSOptions||IDv||Times||||Nonce2||Tickettgs||Authenticatorc
(4) TGS C Realmc||IDc||Ticketv||E(Kc,tgs,
[Kc,v||Times||Nonce2||Realmv||IDv])
Tickettgs = E(Ktgs,
[Flags||KC,tgs||Realmc||IDC||ADC||Times])
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADc||Times])
Authenticatorc = E(Kc,tgs, [IDC||Realmc||TS1])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
5) C V Options||Ticketv||Authenticatorc
(6) V C EKc,v[TS2||Subkey||Seq#]
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADC||Times])
Authenticatorc = E(Kc,v,[IDC||Realmc||TS2||Subkey||Seq#])
64
(c) Client/Server Authentication Exchange to obtainservice
These are the authentication dialogues used in Kerberos.
12) Describe the authentication dialogue used by Kerberosfor obtaining required services.Ans)1) In an unprotected network environment, any client can apply to
any server for service. The obvious security risk is that of
impersonation.
2) An opponent can pretend to be another client and obtain
unauthorized privileges on server machines. To counter this
threat, servers must be able to confirm the identities of clients
who request service.
3) Each server can be required to undertake this task for each
client/server interaction, but in an open environment, this
places a substantial burden on each server.
4) An alternative is to use an authentication server (AS) that
knows the passwords of all users and stores these in a
centralized database.
5) In addition, the AS shares a unique secret key with each
server. These keys have been distributed physically or in some
65
other secure manner. Consider the following hypothetical
dialogue:
The portion to the left of the colon indicates the sender and
receiver; the portion to the right indicates the contents
of the message, the symbol || indicates concatenation
(1) C -> AS: IDC||PC||IDV
(2) AS -> C: Ticket
(3) C -> V: IDC||Ticket
Ticket = E (Kv, [IDC||ADC||IDV])
Where
C = client
AS = authentication server
V =server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
Kv = secret encryption key shared by AS and V
66
Although the foregoing scenario solves some of the problems of
authentication in an open network environment, problems remain.
Two in particular stand out. First, we would like to minimize the
number of times that a user has to enter a password. Suppose
each ticket can be used only once. If user C logs on to a
workstation in the morning and wishes to check his or her mail at
a mail server, C must supply a password to get a ticket for the
mail server. If C wishes to check the mail several times during the
day, each attempt requires re entering the password. We can
improve matters by saying that tickets are reusable. For a single
logon session, the workstation can store the mail server ticket
after it is received and use it on behalf of the user for multiple
accesses to the mail server.
However, under this scheme it remains the case that a user would
need a new ticket for every different service. If a user wished to
access a print server, a mail server, a file server, and so on, the
first instance of each access would require a new ticket and
hence require the user to enter the password.
The second problem is that the earlier scenario involved a
plaintext transmission of the password [message (1)]. An
eavesdropper could capture the password and use any service
accessible to the victim.
To solve these additional problems, we introduce a scheme for
avoiding plaintext passwords and a new server, known as the
67
ticket-granting server (TGS). The new but still hypothetical
scenario is as follows:
Once per user logon session:
(1) C -> AS: IDC||IDtgs
(2) AS -> C: E(Kc, Tickettgs)
Once per type of service:
(3) C -> TGS: IDC||IDV| |Tickettgs
(4) TGS -> C: Ticketv
Once per service session:(5) C -> V: IDC||Ticketv
Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])
Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])
The new service, TGS, issues tickets to users who have been
authenticated to AS. Thus, the user first requests a ticket-granting
ticket(Tickettgs) from the AS. The client module in the user
workstation saves this ticket. Each time the user requires access
to a new service, the client applies to the TGS, using the ticket to
68
authenticate itself. The TGS then grants a ticket for the particular
service. The client save search service-granting ticket and uses it
to authenticate its user to a server each time a particular service
is requested.
Kerberos V4Although the foregoing scenario enhances security compared
to the first attempt, two additional problems remain. The heart of
the first problem is the lifetime associated with the ticket-granting
ticket. If this lifetime is very short (e.g., minutes), then the user will
be repeatedly asked for a password. If the lifetime is long (e.g.,
hours), then an opponent has a greater opportunity for replay. An
opponent could eavesdrop on the network and capture a copy of
the ticket-granting ticket and then wait for the legitimate user to
log out. Then the opponent could forge the legitimate user's
network address and send the message of step (3) to the TGS.
This would give the opponent unlimited access to the resources
and files available to the legitimate user.
Similarly, if an opponent captures a service-granting ticket and
uses it before it expires, the opponent has access to the
corresponding service.
Thus, we arrive at an additional requirement. A network service
(the TGS or an application service) must be able to prove that the
69
person using a ticket is the same person to whom that ticket was
issued.
The second problem is that there may be a requirement for
servers to authenticate themselves to users. Without such
authentication, an opponent could sabotage the configuration so
that messages to a server were directed to another location. The
false server would then be in a position to act as a real server and
capture any information from the user and deny the true service to
the user.
(1) C-> AS IDc||IDtgs||TS1
(2) AS-> C E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
Tickettgs = E ( Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])
(a) Authentication Service Exchange to obtain ticket-grantingticket(3) C -> TGS IDv||Tickettgs||Authenticatorc
(4) TGS-> C E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv])
Tickettgs = E(Ktgs, [Kc,tgs||IDC||ADC||IDtgs||TS2||Lifetime2])
Ticketv = E(Kv, [Kc,v||IDC||ADC||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,tgs, [IDC||ADC||TS3])
70
(b) Ticket-Granting Service Exchange to obtain service-granting ticket(5) C -> V Ticketv||Authenticatorc
(6) V -> C E(Kc,v, [TS5 + 1]) (for mutual authentication)
Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,v,[IDc||ADC||TS5])
Kerberos version5:Kerberos Version 5 is specified in RFC 1510 and provides a
number of improvements over version 4.Lets see the
authentication dialogue of this version.
(1) C AS Options||IDc||Realmc||IDtgs||Times||Nonce1
(2) AS C Realmc||IDC||Tickettgs||E(Kc,
[Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])
Tickettgs = E(Ktgs,
[Flags||Kc,tgs||Realmc||IDc||ADc||Times])
71
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C TGSOptions||IDv||Times||||Nonce2||Tickettgs||Authenticatorc
(4) TGS C Realmc||IDc||Ticketv||E(Kc,tgs,
[Kc,v||Times||Nonce2||Realmv||IDv])
Tickettgs = E(Ktgs,
[Flags||KC,tgs||Realmc||IDC||ADC||Times])
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADc||Times])
Authenticatorc = E(Kc,tgs, [IDC||Realmc||TS1])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
5) C V Options||Ticketv||Authenticatorc
(6) V C EKc,v[TS2||Subkey||Seq#]
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADC||Times])
Authenticatorc = E(Kc,v,[IDC||Realmc||TS2||Subkey||Seq#])
72
(c) Client/Server Authentication Exchange to obtainserviceThese are the authentication dialogues used in Kerberos.
II) Format of X.509 certificate:
ITU-T recommendation X.509 is part of the X.500 series of
recommendations that define a directory service. The directory is,
in effect, a server or distributed set of servers that maintains a
database of information about users. The information includes a
mapping from user name to network address, as well as other
attributes and information about the users.
X.509 defines a framework for the provision of authentication
services by the X.500 directory to its users.
Each certificate contains the public key of a user and is signed
with the private key of a trusted certification authority. In addition,
X.509 defines alternative authentication protocols based on the
use of Public-key certificates.
The heart of the X.509 scheme is the public-key certificate
associated with each user. These user certificates are assumed
to be created by some trusted certification authority (CA) and
73
placed in the directory by the CA or by the user. The directory
server itself is not responsible for the creation of public keys or for
the certification function; it merely provides an easily accessible
location for users to obtain certificates.
The certificate includes following components which is
represented by figure A
Version: Differentiates among successive versions of the
certificate format; the default is version 1. If the Issuer Unique
Identifier or Subject Unique Identifier are present, the value must
be version 2. If one or more extensions are present, the version
must be version 3.
Serial number: An integer value, unique within the issuing CA,
that is unambiguously associated with this certificate.
Signature algorithm identifier: The algorithm used to sign the
certificate, together with any associated parameters. Because this
information is repeated in the Signature field at the end of the
certificate, this field has little, if any, utility.
Issuer name: X.500 name of the CA that created and signed this
certificate.
74
Period of validity: Consists of two dates: the first and last on
which the certificate is valid.
Subject name : The name of the user to whom this certificate
refers. That is, this certificate certifies the public key of the subject
who holds the corresponding private key.
Subject's public-key information: The public key of the subject,
plus an identifier of the algorithm for which this key is to be used,
together with any associated parameters.
Issuer unique identifier: An optional bit string field used to
identify uniquely the issuing CA in the event the X.500 name has
been reused for different entities.
Subject unique identifier: An optional bit string field used to
identify uniquely the subject in the event the X.500 name has
been reused for different entities.
Extensions: A set of one or more extension fields. Extensions
were added in version 3 and are discussed later in this section.
Signature: Covers all of the other fields of the certificate; it
contains the hash code of the other fields, encrypted with the
75
CA's private key. This field includes the signature algorithm
identifier.
Figure A
The unique identifier fields were added in version 2 to handle the
possible reuse of subject and/or issuer names over time. These
fields are rarely used.
The standard uses the following notation to define a certificate:
76
CA<<A>> = CA {V, SN, AI, CA, TA, A, Ap}
where
Y <<X>> = the certificate of user X issued by certification
authority Y
Y {I} = the signing of I by Y. It consists of I with an
encrypted hash code appended
The CA signs the certificate with its private key. If the
corresponding public key is known to a user, then that user can
verify that a certificate signed by the CA is valid. This is the typical
digital signature approach.
---------------------------------------------------------------------------------------
13) Describe the Kerberos Version 4 protocol and Version 5protocol authentication dialogue with technical deficiencies.
Ans: There are technical deficiencies in the version 4
protocol itself. Most of these deficiencies were documented in,
and version 5 attempts to address these. The deficiencies are the
following:
1. Double encryption: Note in [messages (2) and (4)] that tickets
provided to clients are encrypted twice, once with the secret key
of the target server and then again with a secret key known to the
client. The second encryption is not necessary and is
computationally wasteful.
77
2. PCBC encryption: Encryption in version 4 makes use of a
nonstandard mode of DES known as propagating cipher block
chaining (PCBC). It has been demonstrated that this mode is
vulnerable to an attack involving the interchange of cipher text
blocks. PCBC was intended to provide an integrity check as part
of the encryption operation. Version 5 provides explicit integrity
mechanisms, allowing the standard CBC mode to be used for
encryption. In particular, a checksum or hash code is attached to
the message prior to encryption using CBC.
3. Session keys: Each ticket includes a session key that is used
by the client to encrypt the authenticator sent to the service
associated with that ticket. In addition, the session key may
subsequently be used by the client and the server to protect
messages passed during that session. However, because the
same ticket may be used repeatedly to gain service from a
particular server, there is the risk that an opponent will replay
messages from an old session to the client or the server. In
version 5, it is possible for a client and server to negotiate a sub
session key, which is to be used only for that one connection. A
new access by the client would result in the use of a new sub
session key.
4. Password attacks: Both versions are vulnerable to a
password attack. The message from the AS to the client includes
material encrypted with a key based on the client's password. An
opponent can capture this message and attempt to decrypt it by
78
trying various passwords. If the result of a test decryption is of the
proper form, then the opponent has discovered the client's
password and may subsequently use it to gain authentication
credentials from Kerberos. With the same kinds of
countermeasures being applicable. Version 5 does provide a
Mechanism known as pre authentication, which should make
password attacks more difficult, but it does not prevent them.
---------------------------------------------------------------------------------------
14) Explain about KerberosAns:Kerberos is an authentication service developed as part of
Project Athena at MIT. The problem that Kerberos addresses is
this: Assume an open distributed environment in which users at
workstations wish to access services on servers distributed
throughout the network. We would like for servers to be able to
restrict access to authorized users and to be able to authenticate
requests for service. In this environment, a workstation cannot be
trusted to identify its users correctly to network services. In
particular, the following three threats exist: "In Greek mythology, a
many headed dog, commonly three, perhaps with a serpent's tail,
the guardian of the entrance of Hades." Just as the Greek
Kerberos has three heads, the modern Kerberos was intended to
have three components to guard a network's gate: authentication,
accounting, and audit. The last two heads were never
implemented.
79
A user may gain access to a particular workstation and pretend to
be another user operating from that workstation.
A user may alter the network address of a workstation so that the
requests sent from the altered workstation appear to come from
the impersonated workstation. A user may eavesdrop on
exchanges and use a replay attack to gain entrance to a server or
to disrupt operations. In any of these cases, an unauthorized user
may be able to gain access to services and data that he or she is
not authorized to access. Rather than building in elaborate
authentication protocols at each server, Kerberos provides a
centralized authentication server whose function is to authenticate
users to servers and servers to users. Unlike most other
authentication schemes described in this book, Kerberos relies
exclusively on symmetric encryption, making no use of public-key
encryption. Two versions of Kerberos are in common use. Version
4 implementations still exist. Version 5 corrects some of the
security deficiencies of version 4 and has been issued as a
proposed Internet Standard (RFC 1510). Versions 1 through 3
were internal development versions. Version 4 is the "original"
Kerberos. We begin this section with a brief discussion of the
motivation for the Kerberos approach. Then, because of the
complexity of Kerberos, it is best to start with a description of the
authentication protocol used in version 4. This enables us to see
the essence of the Kerberos strategy without considering some of
80
the details required to handle subtle security threats. Finally, we
examine version 5.
Motivation
If a set of users is provided with dedicated personal computers
that have no network connections, then a user's resources and
files can be protected by physically securing each personal
computer. When these users instead are served by a centralized
time-sharing system, the time-sharing operating system must
provide the security. The operating system can enforce access
control policies based on user identity and use the logon rocedure
to identify users. Today, neither of these scenarios is typical.
More common is a distributed architecture consisting of dedicated
user workstations (clients) and distributed or centralized servers.
In this environment, three approaches to security can be
envisioned: Rely on each individual client workstation to assure
the identity of its user or users and rely on each server to enforce
a security policy based on user identification (ID). Require that
client systems authenticate themselves to servers, but trust the
client system concerning the identity of its user.
Require the user to prove his or her identity for each service
invoked. Also require that servers prove their identity to clients. In
a small, closed environment, in which all systems are owned and
operated by a single organization, the first or perhaps the second
strategy may suffice.
81
But in a more open environment, in which network connections to
other machines are supported, the third approach is needed to
protect user information and resources housed at the server.
Kerberos supports this third approach. Kerberos assumes
distributed client/server architecture and employs one or more
Kerberos servers to provide an authentication service.
The first published report on Kerberos listed the following
requirements:
Secure: A network eavesdropper should not be able to obtain the
necessary information to impersonate a user. More generally,
Kerberos should be strong enough that a potential opponent does
not find it to be the weak link.
Reliable: For all services that rely on Kerberos for access control,
lack of availability of the Kerberos service means lack of
availability of the supported services. Hence, Kerberos should be
highly reliable and should employ a distributed server
architecture, with one system able to back up another.
Transparent: Ideally, the user should not be aware that
authentication is taking place, beyond the requirement to enter a
password.
Scalable: The system should be capable of supporting large
numbers of clients and servers. This suggests a modular,
distributed architecture.
82
15) i)Define Kerberos?
Ans: Kerberos:
is an authentication service developed as part of Project Athena
at MIT. Kerberos provides a centralized authentication server
whose function is to authenticate users to servers and servers to
users.
Kerberos relies exclusively on symmetric encryption, making no
use of public-key encryption.
Two versions of Kerberos are in common use. Version 4 [MILL88,
STEI88] implementations still exist. Version 5 [KOHL94] corrects
some of the security deficiencies of version 4 and has been
issued as a proposed Internet Standard (RFC 1510).
Kerberos
assumes a distributed client/server architecture and employs
one or more Kerberos servers to provide an authentication
service.
[3] However, even a closed environment faces the threat of attack
by a disgruntled employee.
The first published report on Kerberos [STEI88] listed the
following requirements:
Secure: A network eavesdropper should not be able to obtain the
necessary information to impersonate a user. More generally,
83
Kerberos should be strong enough that a potential opponent does
not find it to be the weak link.
Reliable: For all services that rely on Kerberos for access control,
lack of availability of the Kerberos service means lack of
availability of the supported services. Hence, Kerberos should be
highly reliable and should employ a distributed server
architecture, with one system able to back up another.
Transparent: Ideally, the user should not be aware that
authentication is taking place, beyond the requirement to enter a
password.
Scalable: The system should be capable of supporting large
numbers of clients and servers. This suggests a modular,
distributed architecture.
ii)in the content of kerberos what is relam?
Ans: A full-service Kerberos environment consisting of a Kerberos
server, a number of clients, and a number of application servers
requires the
following:
1The Kerberos server must have the user ID and hashed
passwords of all participating users in its database. All users are
registered with the Kerberos server.
84
2. The Kerberos server must share a secret key with each server.
All servers are registered with the Kerberos server.
Such an environment is referred to as a Kerberos realm. The
concept of realm can be explained as follows. A Kerberos realm is
a set of managed nodes that share the same Kerberos database.
The Kerberos database resides on the Kerberos master computer
system, which should be kept in a physically secure room. A read-
only copy of the Kerberos database might also reside on other
Kerberos computer systems. However, all changes to the
database must be made on the master computer system.
Changing or accessing the contents of a Kerberos database
requires the Kerberos master password. A related concept is that
of a Kerberos principal, which is a service or user
that is known to the Kerberos system. Each Kerberos principal is
identified by its principal name. Principal names consist of three
parts: a service or user name, an instance name, and a realm
name
Networks of clients and servers under different administrative
organizations typically constitute different realms. That is, it
generally is not practical, or does not conform to administrative
policy, to have users and servers in one administrative domain
registered with a Kerberos
85
server elsewhere. However, users in one realm may need access
to servers in other realms, and some servers may be willing to
provide service to users from other realms, provided that those
users are authenticated. Kerberos provides a mechanism for
supporting such interrealm authentication. For two realms to
support interrealm authentication, a third requirement is added:
The Kerberos server in each interoperating realm shares a secret
key with the server in the other realm. The two Kerberoservers
are registered with each other.
iii)Assume the client C wants to communicate server S usingKerberos procedure .How can it be achieved?
Ans: (1) C ->AS: IDc||IDtgs||TS1
(2) AS ->C :E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
Tickettgs = E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C ->TGS: IDv||Tickettgs||Authenticatorc
(4) TGS ->C: E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv])
86
Tickettgs = E(Ktgs, [Kc,tgs||IDC||ADC||IDtgs||TS2||Lifetime2])
Ticketv = E(Kv, [Kc,v||IDC||ADC||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,tgs, [IDC||ADC||TS3])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
(5) C ->V: Ticketv||Authenticatorc
(6) V ->C : E(Kc,v, [TS5 + 1]) (for mutual authentication)
Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,v,[IDc||ADC||TS5])
(c) Client/Server Authentication Exchange to obtain service
where
C = client
AS = authentication server
V =server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
Kv = secret encryption key shared by AS and V
87
16)How does PGP provides confidentiality and authenticationservice for E-mail and file storage application?Draw theblock diagram and explain its components?
Ans:
88
The message component includes the actual data to be stored
or transmitted, as well as a filename and a timestamp that
specifies the time of creation.
The signature component includes the following:
Timestamp: The time at which the signature was made.
Message digest: The 160-bit SHA-1 digest, encrypted with the
sender's private signature key. The digest is calculated over the
signature timestamp concatenated with the data portion of the
message component. The inclusion of the signature timestamp in
the digest assures against replay types of attacks. The exclusion
of the filename and timestamp portions of the message
component ensures that detached signatures are exactly the
same as attached signatures prefixed to the message.
Detached signatures are calculated on a separate file that has
none of the message component header fields.
Leading two octets of message digest: To enable the recipient
to determine if the correct public key was used to decrypt the
message digest for authentication, by comparing this plaintext
copy of the first two octets with the first two octets of the
decrypted digest. These octets also serve as a 16-bit frame check
sequence for the message.
89
Key ID of sender's public key: Identifies the public key that
should be used to decrypt the message digest and, hence,
identifies the private key that was used to encrypt the message
digest.
The message component and optional signature component may
be compressed using ZIP and may be encrypted using a session
key.
The session key component includes the session key and the
identifier of the recipient's public key that was used by the sender
to encrypt the session key.
The entire block is usually encoded with radix-64 encoding.
Key Rings
We have seen how key IDs are critical to the operation of PGP
and that two key IDs are included in any PGP message that
provides both confidentiality and authentication. These keys need
to be stored and organized in a systematic way for efficient and
effective use by all parties. The scheme used in PGP is to provide
a pair of data structures at each node, one to store the
public/private key pairs owned by that node and one to store the
public keys of other users known at this node. These data
structures are referred to, respectively, as the private-key ring and
the public-key ring.
90
Figure 15.4 shows the general structure of a private-key ring.
We can view the ring as a table, in which each row represents
one of the public/private key pairs owned by this user. Each row
contains the following entries:
Timestamp: The date/time when this key pair was generated.
Key ID: The least significant 64 bits of the public key for this
entry.
Public key: The public-key portion of the pair.
Private key: The private-key portion of the pair; this field is
encrypted.
User ID: Typically, this will be the user's e-mail address (e.g.,
[email protected]). However, the user may choose to associate
a different name with each pair (e.g., Stallings, WStallings,
WilliamStallings, etc.) or to reuse the same User ID more than
once.
91
Figure 15.4. General Structure of Private- and Public-KeyRings
Figure 15.4 also shows the general structure of a public-keyring. This data structure is used to store public keys of other
users that are
known to this user. For the moment, let us ignore some fields
shown in the table and describe the following fields:
Timestamp: The date/time when this entry was generated.
Key ID: The least significant 64 bits of the public key for this
entry.
92
Public Key: The public key for this entry.
User ID: Identifies the owner of this key. Multiple user IDs may be
associated with a single public key.
Confidentiality and Authenticatio
Both services may be used for the same message. First, a
signature is generated for the plaintext message and prepended
to the message. Then the plaintext message plus signature is
encrypted using CAST-128 (or IDEA or 3DES), and the session
key is encrypted using RSA (or ElGamal). This sequence is
preferable to the opposite: encrypting the message and then
generating a signature for the encrypted message. It is generally
more convenient to store a signature with a plaintext version of a
message.
Furthermore, for purposes of third-party verification, if the
signature is performed first, a third party need not be concerned
with the symmetric key when verifying the signature.
In summary, when both services are used, the sender first signs
the message with its own private key, then encrypts the message
with a session key, and then encrypts the session key with the
recipient's public key.
93
17.)Explain content types of MIME?
Ans. The bulk of the MIME specification is concerned with the
definition of a variety of content types. This reflects the need to
provide standardized ways of dealing with a wide variety of
information representations in a multimedia environment. There
are seven different major types of content and a total of 15
subtypes. In general, a content type declares the general type of
data, and the subtype specifies a particular format for that type of
data. For the text type of body, no special software is required to
get the full meaning of the text, aside from support of the
indicated character set. The primary subtype is plain text, which is
simply a string of ASCII characters or ISO 8859 characters.
The enriched subtype allows greater formatting flexibility. The
multipart type indicates that the body contains multiple,
independent parts. The Content-Type header field includes a
parameter, called boundary that defines the delimiter between
body parts. This boundary should not appear in any parts of the
message. Each boundary starts on a new line and consists of two
hyphens followed by the boundary value. The final boundary,
which indicates the
end of the last part, also has a suffix of two hyphens. Within each
part, there may be an optional ordinary MIME header. Here is a
simple example of a multipart message, containing two parts both
consisting of simple text (taken from RFC 2046): From: Nathaniel
Borenstein <[email protected]>
94
To: Ned Freed <[email protected]>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored, though it is a handy
Place for mail composers to include an explanatory note to non-
MIME conformant readers.--simple boundary
This is implicitly typed plain ASCII text. It does NOT end with a
line break.--simple boundary
Content-type: text/plain; charset=us-ascii
This is expIicitly typed plain ASCII text. It DOES end with a
Iinebreak.
--simple boundary--
This is the epilogue. It is also to be ignored. There are four
subtypes of the multipart type, all of which have the same overall
syntax. The multipartlmixed subtype is used when there are
multiple independent body parts that need to be bundled in a
particular order. For the multipart/parallel subtype, the order of
the parts is not significant. If the recipient's system is appropriate,
the multiple parts can be presented in parallel. For example, a
95
picture or text part could be accompanied by a voice commentary
that is played while the picture or text is displayed. For the
multipart alternative subtype, the various parts are different
representations of the same information. The following is an
example:
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... plain text version of message goes here ....
--boundary42
Content-Type: text/enriched
.... RFC 1896 text/enriched version of same message goes here ...
--boundary42--
In this subtype, the body parts are ordered in terms of increasing
preference.
For this example, if the recipient system is capable of displaying
the message in the text/enriched format, this is done; otherwise,
the plain text format is used.
The muItipartldigest subtype is used when each of the body parts
is interpreted
96
as an RFC 822 message with headers. This subtype enables the
construction of a message whose parts are individual messages.
For example, the moderator of a group might collect e-mail
messages from participants, bundle these messages, and send
them out in one encapsulating MIME message. The message
type provides a number of important capabilities in MIME. The
message/rfc822 subtype indicates that the body is an entire
message, including header and body.
Despite the name of this subtype, the encapsulated message may
be not only a simple RFC 822 message, but any MIME message.
The message/partial subtype enables fragmentation of a large
message into a number of parts, which must be reassembled at
the destination. For this subtype, three parameters are specified
in the Content-Type: Message/Partial field: an id common to all
fragments of the same message, a sequence number unique to
each fragment, and the total number of fragments.
The message/external-body subtype indicates that the actual data
to be conveyed in this message are not contained in the body.
Instead, the body contains the information needed to access the
data. As with the other message types, the message/ external-
body subtype has an outer header and an encapsulated message
with its own header.
The only necessary field in the outer header is the Content-Type
field, which identifies this as a message/external-body subtype.
The inner header is the message header for the encapsulated
97
message. The Content-Type field in the outer header must
include an access-type parameter, which indicates the method of
access, such as FTP (file transfer protocol). The application type
refers to other kinds of data, typically either uninterrupted binary
data or information to be processed by a mail-based application.
--------------------------------------------------------------------------------------
18.) Describe how PGP provides confidentiality andAuthentication service for email applications?Ans. The actual operation of PGP, as opposed to the
management of keys, consists of five services: authentication,
confidentiality, compression, e-mail Compatibility, and
segmentation.
Confidentiality and AuthenticationAs Figure 5.1c illustrates, both services may be used for the same
message.
First, a signature is generated for the plaintext message and
prepended to the message. Then the plaintext message plus
signature is encrypted using CAST -128 (or IDEA or 3DES), and
the session key is encrypted using RSA (or ElGamal). This
sequence is preferable to the opposite: encrypting the message
and then generating a signature for the encrypted message. It is
generally more convenient to stare a signature with a plaintext
version of a message. Furthermore, for purposes of third-party
verification, if the signature is performed first, a third party need
not be concerned with the symmetric key when verifying the
98
signature. In summary, when both services are used, the sender
first signs the message with its own private key, then encrypts the
message with a session key, and then encrypts the session key
with the recipient's public key.
Authentication:The sequence is as follows:
1. The sender creates a message.
2. SHA-l is used to generate a 160-bithash code of the message.
3. The hash code is encrypted with RSA using the sender's
private key, and the
result is prepended to the message.
4. The receiver uses RSA with the sender's public key to decrypt
and recover
the hash code.
5. The receiver generates a new hash code for the message and
compares it with
the decrypted hash code. If the two match, the message is
accepted as authentic.
The combination of SHA-l and RSA provides an effective
digital signature
scheme. Because of the strength of RSA, the recipient is assured
that only the
Possessor of the matching private key can generate the
signature. Because of
99
the strength of SHA-l, the recipient is assured that no one else
could generate a
new message that matches the hash code and, hence, the
signature of the original message.
Confidentiality:Another basic service provided by PGP is confidentiality, which is
provided by
encrypting messages to be transmitted or to be stored locally as
files. In both cases, the symmetric encryption algorithm CAST-
128 may be used. Alternatively, IDEA or 3DES may be used. The
64-bit cipher feedback (CFB) mode is used. As always, one must
address the problem of key distribution. In PGP, each symmetric
key is used only once. That is, a new key is generated as a
random 128- bit number for each message. Thus, although this is
referred to in the documentation as a session key, it is in reality a
one-time key. Because it is to be used only once, the session key
is bound to the message and transmitted with it. To protect the
key, it is encrypted with the receiver's public key. which can be
described as follows:
1. The sender generates a message and a random 128-bit
number to be used as a
session key for this message only.
2. The message is encrypted, using CAST-128 (or IDEA or 3DES)
with the
session key.
100
3. The session key is encrypted with RSA, using the recipient's
public key, and
is prepended to the message.
4. The receiver uses RSA with its private key to decrypt and
recover the session key.
5. The session key is used to decrypt the message.
As an alternative to the use of RSA for key encryption, PGP
provides an
option referred to as Diffie-Hellman. As was explained in Chapter
3, Diffie-Hellman is a key exchange algorithm. In fact, PGP uses
a variant of Diffie-Hellman that does provide
encryption/decryption, known as ElGamal.