Unit 3
Unit 3
Unit 3
=
+
=
=
2 1
1
2
1
2 1
1 2
1 2
_
2
3
_
x x for
y
a x
x x for
x x
y y
An elliptic curve may be defined over any finite field GF(q). For GF(2
m
), the curve has a
different form:- y
2
+ xy = x
3
+ ax
2
+ b, where b = 0.
Cryptography with Elliptic Curves
The addition operation in ECC is the counterpart of modular multiplication in RSA,
and multiple addition is the counterpart of modular exponentiation. To form a
cryptographic system using elliptic curves, some kind of hard problem such as discrete
logarithm or factorization of prime numbers is needed. Considering the equation, Q=kP,
where Q,P are points in an elliptic curve, it is easy to compute Q given k,P , but hard to
find k given Q,P. This is known as the elliptic curve logarithm problem. k could be so large as
to make brute-force fail.
ECC Key Exchange
Pick a prime number p= 2
180
and elliptic curve parameters a and b for the equation
y
2
x
3
+ ax + b (mod p) which defines the elliptic group of points E
p
(a,b). Select generator
point G=(x
1
,y
1
) in E
p
(a,b) such that the smallest value for which nG=O be a very large prime
number. E
p
(a,b) and G are parameters of the cryptosystem known to all participants. The
following steps take place:
A & B select private keys n
A
<n, n
B
<n
compute public keys: P
A
=n
A
G, P
B
=n
B
G
compute shared key: K=n
A
P
B
,
K=n
B
P
A
{same since K=n
A
n
B
G }
ECC Encryption/Decryption
As with key exchange system, an encryption/decryption system requires a point G and and
elliptic group E
p
(a,b) as parameters. First thing to be done is to encode the plaintext
message m to be sent as an x-y point P
m
. Each user chooses private key n
A
<n and computes
public key P
A
=n
A
G. To encrypt and send a message to P
m
to B, A chooses a random positive
integer k and produces the ciphertext C
m
consisting of the pair of points C
m
={kG, P
m
+kP
b
}.
here, A uses Bs public key. To decrypt the ciphertext, B multiplies the first point in the pair
by Bs secret key and subtracts the result from the second point
P
m
+kP
b
n
B
(kG) = P
m
+k(n
B
G) n
B
(kG) = P
m
A has masked the message P
m
by adding kP
b
to it. Nobody but A knows the value of k, so
even though P
b
is a public key, nobody can remove the mask kP
b.
For an attacker to recover
the message, he has to compute k given G and kG, which is assumed hard.
Security of ECC
To protect a 128 bit AES key it would take a RSA Key Size of 3072 bits whereas an
ECC Key Size of 256 bits.
Hence for similar security ECC offers significant computational advantages.
Applications of ECC:
- Wireless communication devices
- Smart cards
- Web servers that need to handle many encryption sessions
- Any application where security is needed but lacks the power, storage and
computational power that is necessary for our current cryptosystems
Digital Signature
The most important development from the work on public-key cryptography is the digital
signature. Message authentication protects two parties who exchange messages from any
third party. However, it does not protect the two parties against each other. A digital
signature is analogous to the handwritten signature, and provides a set of security
capabilities that would be difficult to implement in any other way. It must have the
following properties:
It must verify the author and the date and time of the signature
It must to authenticate the contents at the time of the signature
It must be verifiable by third parties, to resolve disputes
Thus, the digital signature function includes the authentication function. A variety of
approaches has been proposed for the digital signature function. These approaches fall into
two categories: direct and arbitrated.
Direct Digital Signature
Direct Digital Signatures involve the direct application of public-key algorithms involving
only the communicating parties. A digital signature may be formed by encrypting the entire
message with the senders private key, or by encrypting a hash code of the message with
the senders private key. Confidentiality can be provided by further encrypting the entire
message plus signature using either public or private key schemes. It is important to
perform the signature function first and then an outer confidentiality function, since in case
of dispute, some third party must view the message and its signature. But these approaches
are dependent on the security of the senders private-key. Will have problems if it is
lost/stolen and signatures forged. Need time-stamps and timely key revocation.
Arbitrated Digital Signature
The problems associated with direct digital signatures can be addressed by using an arbiter,
in a variety of possible arrangements. The arbiter plays a sensitive and crucial role in this
sort of scheme, and all parties must have a great deal of trust that the arbitration
mechanism is working properly. These schemes can be implemented with either private or
public-key algorithms, and the arbiter may or may not see the actual message contents.
Using Conventional encryption
X A : M || E ( K
xa
,[ ID
x
|| H (M) ] )
A Y : E( K
ay
,[ ID
x
|| M || E (K
xa
,[ ID
x
||H(M))] ) || T ])
It is assumed that the sender X and the arbiter A share a secret key K
xa
and that A
and Y share secret key K
ay
. X constructs a message M and computes its hash value
H(m) . Then X transmits the message plus a signature to A. the signature consists of
an identifier ID
x
of X plus the hash value, all encrypted using K
xa
.
A decrypts the signature and checks the hash value to validate the message. Then A
transmits a message to Y, encrypted with K
ay
. The message includes ID
x
, the original
message from X, the signature, and a timestamp.
Arbiter sees message
Problem : the arbiter could form an alliance with sender to deny a signed message,
or with the receiver to forge the senders signature.
Using Public Key Encryption
X A : ID
x
||E( PR
x
,[ ID
x
|| E ( PU
y
, E( PR
x
, M))])
A Y : E( PR
a
, [ ID
x
||E (PU
y
, E (PR
x
, M))|| T] )
X double encrypts a message M first with Xs private key,PR
x
, and then with Ys public
key, PU
y
. This is a signed, secret version of the message. This signed message,
together with Xs identifier , is encrypted again with PR
x
and, together with ID
x
, is
sent to A. The inner, double encrypted message is secure from the arbiter (and
everyone else except Y)
A can decrypt the outer encryption to assure that the message must have come from
X (because only X has PR
x
). Then A transmits a message to Y, encrypted with PR
a
. The
message includes ID
x
, the double encrypted message, and a timestamp.
Arbiter does not see message
Digital Signature Standard (DSS)
The National Institute of Standards and Technology (NIST) has published Federal
Information Processing Standard FIPS 186, known as the Digital Signature Standard (DSS).
The DSS makes use of the Secure Hash Algorithm (SHA) and presents a new digital signature
technique, the Digital Signature Algorithm (DSA). The DSS uses an algorithm that is designed
to provide only the digital signature function and cannot be used for encryption or key
exchange, unlike RSA.
The RSA approach is shown below. The message to be signed is input to a hash function that
produces a secure hash code of fixed length. This hash code is then encrypted using the
sender's private key to form the signature. Both the message and the signature are then
transmitted.
The recipient takes the message and produces a hash code. The recipient also decrypts the
signature using the sender's public key. If the calculated hash code matches the decrypted
signature, the signature is accepted as valid. Because only the sender knows the private key,
only the sender could have produced a valid signature.
The DSS approach also makes use of a hash function. The hash code is provided as input to a
signature function along with a random number k generated for this particular signature.
The signature function also depends on the sender's private key (PR
a
) and a set of
parameters known to a group of communicating principals. We can consider this set to
constitute a global public key (PU
G
).The result is a signature consisting of two components,
labeled s and r.
At the receiving end, the hash code of the incoming message is generated. This plus the
signature is input to a verification function. The verification function also depends on the
global public key as well as the sender's public key (PU
a
), which is paired with the sender's
private key. The output of the verification function is a value that is equal to the signature
component r if the signature is valid. The signature function is such that only the sender,
with knowledge of the private key, could have produced the valid signature.
KERBEROS
Kerberos
is an authentication service developed as part of Project Athena at MIT. It
addresses the threats posed in an open distributed environment in which users at
workstations wish to access services on servers distributed throughout the network. Some
of these threats are:
- 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.
Two versions of Kerberos are in current use: Version-4 and Version-5. 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
Two versions of Kerberos are in common use: Version 4 is most widely used version. Version
5 corrects some of the security deficiencies of Version 4. Version 5 has been issued as a
draft Internet Standard (RFC 1510)
Kerberos Version 4
1.) Simple dialogue:
More Secure Dialogue
The Version 4 Authentication Dialogue
The full Kerberos v4 authentication dialogue is shown here divided into 3 phases.
There is a problem of captured ticket-granting tickets and the need to determine that the
ticket presenter is the same as the client for whom the ticket was issued. An efficient way of
doing this is to use a session encryption key to secure information.
Message (1) includes a timestamp, so that the AS knows that the message is timely.
Message (2) includes several elements of the ticket in a form accessible to C. This enables C
to confirm that this ticket is for the TGS and to learn its expiration time. Note that the ticket
does not prove anyone's identity but is a way to distribute keys securely. It is the
authenticator that proves the client's identity. Because the authenticator can be used only
once and has a short lifetime, the threat of an opponent stealing both the ticket and the
authenticator for presentation later is countered. C then sends the TGS a message that
includes the ticket plus the ID of the requested service (message 3). The reply from the TGS,
in message (4), follows the form of message (2). C now has a reusable service-granting ticket
for V. When C presents this ticket, as shown in message (5), it also sends an authenticator.
The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If
mutual authentication is required, the server can reply as shown in message (6).
Overview of Kerberos
Kerberos Realms
A full-service Kerberos environment consisting of a Kerberos server, a number of clients,
and a number of application servers is referred to as a Kerberos realm. A Kerberos realm is a
set of managed nodes that share the same Kerberos database, and are part of the same
administrative domain. If have multiple realms, their Kerberos servers must share keys and
trust each other.
The following figure shows the authentication messages where service is being
requested from another domain. The ticket presented to the remote server indicates the
realm in which the user was originally authenticated. The server chooses whether to honor
the remote request. One problem presented by the foregoing approach is that it does not
scale well to many realms, as each pair of realms need to share a key.
The limitations of Kerberos version-4 are categorised into two types:
Environmental shortcomings of Version 4:
Encryption system dependence: DES
Internet protocol dependence
Ticket lifetime
Authentication forwarding
Inter-realm authentication
Technical deficiencies of Version 4:
Double encryption
Session Keys
Password attack
Kerberos version 5
Kerberos Version 5 is specified in RFC 1510 and provides a number of improvements over
version 4 in the areas of environmental shortcomings and technical deficiencies. It includes
some new elements such as:
Realm: Indicates realm of the user
Options
Times
From: the desired start time for the ticket
Till: the requested expiration time
Rtime: requested renew-till time
Nonce: A random value to assure the response is fresh
The basic Kerberos version 5 authentication dialogue is shown here First, consider the
authentication service exchange.
Message (1) is a client request for a ticket-granting ticket.
Message (2) returns a ticket-granting ticket, identifying information for the client, and a
block encrypted using the encryption key based on the user's password. This block includes
the session key to be used between the client and the TGS.
Now compare the ticket-granting service exchange for versions 4 and 5. See that message
(3) for both versions includes an authenticator, a ticket, and the name of the requested
service. In addition, version 5 includes requested times and options for the ticket and a
nonce, all with functions similar to those of message (1). The authenticator itself is
essentially the same as the one used in version 4. Message (4) has the same structure as
message (2), returning a ticket plus information needed by the client, the latter encrypted
with the session key now shared by the client and the TGS. Finally, for the client/server
authentication exchange, several new features appear in version 5, such as a request for
mutual authentication. If required, the server responds with message (6) that includes the
timestamp from the authenticator. The flags field included in tickets in version 5 supports
expanded functionality compared to that available in version 4.
Advantages of Kerberos:
User's passwords are never sent across the network, encrypted or in plain text
Secret keys are only passed across the network in encrypted form
Client and server systems mutually authenticate
It limits the duration of their users' authentication.
Authentications are reusable and durable
Kerberos has been scrutinized by many of the top programmers, cryptologists and
security experts in the industry
X.509 Authentication Service
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 is based on the use of public-key cryptography and digital signatures.
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 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 general format of a certificate is shown above, which includes the following elements:
version 1, 2, or 3
serial number (unique within CA) identifying certificate
signature algorithm identifier
issuer X.500 name (CA)
period of validity (from - to dates)
subject X.500 name (name of owner)
subject public-key info (algorithm, parameters, key)
issuer unique identifier (v2+)
subject unique identifier (v2+)
extension fields (v3)
signature (of hash of all fields in certificate)
The standard uses the following notation to define a certificate:
CA<<A>> = CA {V, SN, AI, CA, T
A
, 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
User certificates generated by a CA have the following characteristics:
Any user with CAs public key can verify the user public key that was certified
No party other than the CA can modify the certificate without being detected
because they cannot be forged, certificates can be placed in a public directory
Scenario: Obtaining a User Certificate
If both users share a common CA then they are assumed to know its public key. Otherwise
CA's must form a hierarchy and use certificates linking members of hierarchy to validate
other CA's. Each CA has certificates for clients (forward) and parent (backward). Each client
trusts parents certificates. It enables verification of any certificate from one CA by users of
all other CAs in hierarchy.
A has obtained a certificate from the CA X1. B has obtained a certificate from the CA X2. A
can read the Bs certificate but cannot verify it. In order to solve the problem ,the Solution:
X1<<X2> X2<<B>>. A obtain the certificate of X2 signed by X1 from directory. obtain X2s
public key. A goes back to directory and obtain the certificate of B signed by X2. obtain
Bs public key securely. The directory entry for each CA includes two types of certificates:
Forward certificates: Certificates of X generated by other CAs
Reverse certificates: Certificates generated by X that are the certificates of other CAs
X.509 CA Hierarchy
A acquires B certificate using
chain:
X<<W>>W<<V>>V<<Y>>Y<<
Z>> Z<<B>>
B acquires A certificate using
chain:
Z<<Y>>Y<<V>>V<<W>>W<<
X>> X<<A>>
Revocation of Certificates
Typically, a new certificate is issued just before the expiration of the old one. In addition, it
may be desirable on occasion to revoke a certificate before it expires, for one of the
following reasons:
The user's private key is assumed to be compromised.
The user is no longer certified by this CA.
The CA's certificate is assumed to be compromised.
Each CA must maintain a list consisting of all revoked but not expired certificates issued by
that CA, including both those issued to users and to other CAs. These lists should also be
posted on the directory.
Each certificate revocation list (CRL) posted to the directory is signed by the issuer and
includes the issuer's name, the date the list was created, the date the next CRL is scheduled
to be issued, and an entry for each revoked certificate. Each entry consists of the serial
number of a certificate and revocation date for that certificate. Because serial numbers are
unique within a CA, the serial number is sufficient to identify the certificate.
Authentication Procedures
X.509 also includes three alternative authentication procedures that are intended for use
across a variety of applications. All these procedures make use of public-key signatures. It is
assumed that the two parties know each other's public key, either by obtaining each other's
certificates from the directory or because the certificate is included in the initial message
from each side.
1. One-Way Authentication: One way authentication involves a single transfer of
information from one user (A) to another (B), and establishes the details shown above. Note
that only the identity of the initiating entity is verified in this process, not that of the
responding entity. At a minimum, the message includes a timestamp ,a nonce, and the
identity of B and is signed with As private key. The message may also include information to
be conveyed, such as a session key for B.
2. Two-Way Authentication: Two-way authentication thus permits both parties in a
communication to verify the identity of the other, thus additionally establishing the above
details. The reply message includes the nonce from A, to validate the reply. It also includes a
timestamp and nonce generated by B, and possible additional information for A.
3. Three-Way Authentication: Three-Way Authentication includes a final message
from A to B, which contains a signed copy of the nonce, so that timestamps need not be
checked, for use when synchronized clocks are not available.
X.509 Version 3
The X.509 version 2 format does not convey all of the information that recent design and
implementation experience has shown to be needed.
1. The Subject field is inadequate to convey the identity of a key owner to a public-key
user. X.509 names may be relatively short and lacking in obvious identification details
that may be needed by the user.
2. The Subject field is also inadequate for many applications, which typically recognize
entities by an Internet e-mail address, a URL, or some other Internet-related
identification.
3. There is a need to indicate security policy information. This enables a security
application or function, such as IPSec, to relate an X.509 certificate to a given policy.
4. There is a need to limit the damage that can result from a faulty or malicious CA by
setting constraints on the applicability of a particular certificate.
5. It is important to be able to identify different keys used by the same owner at different
times. This feature supports key life cycle management, in particular the ability to
update key pairs for users and CAs on a regular basis or under exceptional
circumstances.
Rather than continue to add fields to a fixed format, standards developers felt that a more
flexible approach was needed. X.509 version 3 includes a number of optional extensions
that may be added to the version 2 format. Each extension consists of an extension
identifier, a criticality indicator, and an extension value. The criticality indicator indicates
whether an extension can be safely ignored or not.