1. Explain the public key cryptographic principles?

shoulderslyricalAI and Robotics

Nov 21, 2013 (3 years and 8 months ago)

89 views

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

1

1. Explain

the public key cryptographic principles?

Public
-
key cryptography

refers to a
cryptographic

system requiring two separate
keys
,
one to lock or encrypt the
plaintext
, and one to unlock or decrypt the
cyphertext
. Neither
key will do both functions. One of these keys is published or public and the other is kept
private. If the lock/encryption key is the one published then the system enables private
communication from the public to the unlocking key's ow
ner. If the unlock/decryption
key is the one published then the system serves as a signature verifier of documents
locked by the owner of the private key. Although in this latter case, since encrypting the
entire message is relatively expensive computation
ally, in practice just a
hash

of the
message is encrypted for signature verification purposes.

This cryptographic approach uses asymmetric key
algorithms

such as
RSA
, hence the
more general name of "asymmetric key cryptography". Some of these algorithms
have
the public key/private key property; that is, neither key is derivable from knowledge of
the other; not all asymmetric key algorithms do. Those with this property are particularly
useful and have been widely deployed, and are the source of the commonl
y used name.
The public key is used to transform a message into an unreadable form,
decrypt able

only
by using the (different but matching) private key. Participants in such a system must
create a mathematically linked key pair. By publishing the public ke
y, the key producer
empowers anyone who gets a copy of the public key to produce messages only s/he can
read
--

because only the key producer has a copy of the private key (required for
decryption). When someone wants to send a secure message to the creato
r of those keys,
the sender encrypts it (i.e., transforms it into an unreadable form) using the intended
recipient's public key; to decrypt the message, the recipient uses the private key. No one
else, including the sender, can do so.

Thus, unlike
symmetric key algorithms
, a public key algorithm does not require a
secure

initial
exchange

of one, or more,
secret keys

between the sender and receiver. These
algorithms work in such a way th
at, while it is easy for the intended recipient to generate
the public and private keys and to decrypt the message using the private key, and while it
is easy for the sender to encrypt the message using the public key, it is extremely difficult
Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

2

for anyone
to figure out the private key based on their knowledge of the public key. They
are based on mathematical relationships (the most notable ones being the
integer
fac
torization

and
discrete logarithm

problems) that have no efficient solution.

The use of these algorithms also allows authenticity of a message to be checked by
creatin
g a
digital signature

of a message using the private key, which can be verified
using the public key.

Public key cryptography is a fundamental and widely used technology.

It is an approach
used by many cryptographic algorithms and
cryptosystems
. It underpins such Internet
standards as
Transport Layer Security (TLS)

(successor to SSL),
PGP
, and
GPG
.



2.
Write

the short notes on public key cryptography algorithms?

A method of encryption and decryption is called a
cipher
. Some cryptographic methods
rely on the secrecy of the algorithms; such algorithms are only of historical inter
est and
are not adequate for real
-
world needs. All modern algorithms use a
key

to control
encryption and decryption; a message can be decrypted only if the key matches the
encryption key.

There are two classes of key
-
based encryption algorithms,
symmetric

(or
secret
-
key
)
and
asymmetric

(or
public
-
key
) algorithms. The difference is that symmetric algorithms
use the same key for encryption and decryption (or the decryption key is easily derived
from the encryption key), whereas asymmetric algorithms use a di
fferent key for
encryption and decryption, and the decryption key cannot be derived from the encryption
key.

Symmetric algorithms can be divided into
stream ciphers

and
block ciphers
. Stream
ciphers can encrypt a single bit of plaintext at a time, whereas

block ciphers take a
number of bits (typically 64 bits in modern ciphers), and encrypt them as a single unit.

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

3

Asymmetric ciphers (also called
public
-
key algorithms

or generally
public
-
key
cryptography
) permit the encryption key to be public (it can even
be published in a
newspaper), allowing anyone to encrypt with the key, whereas only the proper recipient
(who knows the decryption key) can decrypt the message. The encryption key is also
called the
public key

and the decryption key the
private key

or
secr
et key
.

Modern cryptographic algorithms are no longer pencil
-
and
-
paper ciphers. Strong
cryptographic algorithms are designed to be executed by computers or specialized
hardware devices. In most applications, cryptography is done in computer software.

Gen
erally, symmetric algorithms are much faster to execute on a computer than
asymmetric ones. In practice they are often used together, so that a public
-
key algorithm
is used to encrypt a randomly generated encryption key, and the random key is used to
encry
pt the actual message using a symmetric algorithm. This is sometimes called hybrid
encryption



3.

Explain

the given below?

a.

Hash function

b.

Digital Signatures

Digital Signatures

Some public
-
key algorithms can be used to generate
digital signatures
. A digital
s
ignature is a small amount of data that was created using some secret key, and there is a
public key that can be used to verify that the signature was really generated using the
corresponding private key. The algorithm used to generate the signature must b
e such that
without knowing the secret key it is not possible to create a signature that would verify as
valid.

Digital signatures are used to verify that a message really comes from the claimed sender
(assuming only the sender knows the secret key corres
ponding to his/her public key).
Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

4

They can also be used to
timestamp

documents: a trusted party
signs

the document and
its timestamp with his/her secret key, thus testifying that the document existed at the
stated time.

Digital signatures can also be used t
o testify (or
certify
) that a public key belongs to a
particular person. This is done by signing the combination of the key and the information
about its owner by a trusted key. The digital signature by a third party (owner of the
trusted key), the public
key and information about the owner of the public key are often
called
certificates
.

The reason for trusting that third party key may again be signed by another trusted key.
Eventually some key must be a
root

of the trust hierarchy (that is, it is not tru
sted because
it was signed by somebody, but because you believe a priori that the key can be trusted).
In a
centralized key infrastructure

there are very few roots in the trust network (e.g.,
trusted government agencies; such roots are also called
certific
ation authorities
). In a
distributed infrastructure

there need not be any universally accepted roots, and each
party may have different trusted roots (such of the party's own key and any keys signed
by it). This is the
web of trust

concept used in e.g. PGP
.

A digital signature of an arbitrary document is typically created by computing a
message
digest

from the document, and concatenating it with information about the signer, a
timestamp, etc. The resulting string is then encrypted using the private key of
the signer
using a suitable algorithm. The resulting encrypted block of bits is the signature. It is
often distributed together with information about the public key that was used to sign it.
To verify a signature, the recipient first determines whether it

trusts that the key belongs
to the person it is supposed to belong to (using the web of trust or a priori knowledge),
and then decrypts the signature using the public key of the person. If the signature
decrypts properly and the information matches that o
f the message (proper message
digest etc.), the signature is accepted as valid.

Several methods for making and verifying digital signatures are freely available. The
most widely known algorithm is RSA.

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

5

Cryptographic Hash Functions

Cryptographic hash fun
ctions are used in various contexts, for example to compute the
message digest when making a digital signature. A hash function compresses the bits of a
message to a fixed
-
size
hash value

in a way that distributes the possible messages evenly
among the pos
sible hash values. A cryptographic hash function does this in a way that
makes it extremely difficult to come up with a message that would hash to a particular
hash value.

Cryptographic hash functions typically produce hash values of
128

or more bits. Thi
s
number is vastly larger than the number of different messages likely to ever be exchanged
in the world. The reason for requiring more than
128

bits is based on the
birthday
paradox
. The birthday paradox roughly states that given a hash function mapping a
ny
message to an
128
-
bit hash digest, we can expect that the same digest will be computed
twice when
2
64

randomly selected messages have been hashed. As cheaper memory chips
for computers become available it may become necessary to require larger than
128

bit
message digests (such as
160

bits as has become standard recently).

Many good cryptographic hash functions are freely available. The most famous
cryptographic hash functions are those of the MD family, in particular MD4 and MD5.
MD4 has been broken, a
nd MD5, in widespread use, should be still considered secure
until is broken as well. SHA
-
1 and RipeMD
-
160 are two examples that are still
considered state of the art.

Cryptographic Random Number Generators

Cryptographic random number generators generate

random numbers for use in
cryptographic applications, such as for keys. Conventional random number generators
available in most programming languages or programming environments are not suitable
for use in cryptographic applications (they are designed for

statistical randomness, not to
resist prediction by cryptanalysts).

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

6

In the optimal case, random numbers are based on true physical sources of randomness
that cannot be predicted. Such sources may include the noise from a semiconductor
device, the least s
ignificant bits of an audio input, or the intervals between device
interrupts or user keystrokes. The noise obtained from a physical source is then "distilled"
by a cryptographic hash function to make every bit depend on every other bit. Quite often
a larg
e pool (several thousand bits) is used to contain randomness, and every bit of the
pool is made to depend on every bit of input noise and every other bit of the pool in a
cryptographically strong way.

When true physical randomness is not available, pseudo
-
random numbers must be used.
This situation is undesirable, but often arises on general purpose computers. It is always
desirable to obtain some environmental noise
-

even from device latencies, resource
utilization statistics, network statistics, keyboar
d interrupts, or whatever. The point is that
the data must be unpredictable for any external observer; to achieve this, the random pool
must contain at least
128

bits of true entropy.

Cryptographic pseudo
-
random number generators typically have a large po
ol ("seed
value") containing randomness. Bits are returned from this pool by taking data from the
pool, optionally running the data through a cryptographic hash function to avoid
revealing the contents of the pool. When more bits are needed, the pool is st
irred by
encrypting its contents by a suitable cipher with a random key (that may be taken from an
unreturned part of the pool) in a mode which makes every bit of the pool depend on every
other bit of the pool. New environmental noise should be mixed into
the pool before
stirring to make predicting previous or future values even more impossible.

Even though cryptographically strong random number generators are not very difficult to
build if designed properly, they are often overlooked. The importance of th
e random
number generator must thus be emphasized
-

if done
badly;

it will easily become the
weakest point of the system.



Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

7

4.

Management of Kerberos?


Introduction

The Kerberos Identity Management API is a high level API for managing the selection
and manag
ement of Kerberos credentials. It is intended for use by applications, credential
management applications (eg: kinit, kpasswd, etc) and internally by the Kerberos
libraries. Under some circumstances client applications may also benefit from the
Kerberos Id
entity Management API.

API Conventions

Although KIM currently only provides a C API, it attempts to make that API as object
-
oriented as possible. KIM functions are grouped by object and all of the object types are
opaque, including errors. The reason for
this is two
-
fold. First, the KIM API is rather
large. Grouping functions by object allows the API to be broken up into smaller, more
manageable chunks. Second, providing an object
-
like C API will make it easier to port to
object oriented languages.

Becaus
e C lacks classes and other object oriented syntax, KIM functions adhere to the
following naming conventions to make functions easier to identify:



Functions beginning with
kim_object_create

are constructors for an object of
type kim_object. On success the
se functions return a newly allocated object which must
later be freed by the caller.



Functions of the form
kim_object_copy

are copy constructors. They instantiate a
new object of kim_object from an object of the same type.



Functions of the form
kim_obje
ct_free

are destructors for objects of type
kim_object.



Functions beginning with
kim_object_get

and
kim_object_set

examine and
modify properties of objects of type kim_object.

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

8



All KIM APIs except destructors and error management APIs return a KIM Error
o
bject (kim_error_t).

Terminology

Kerberos organizes its authentication tokens by client identity (the name of the user) and
service identity (the name of a service). The following terms are used throughout this
documentation:



credential

-

A token which a
uthenticates a client identity to a service identity.



ccache

-

Short for "credentials cache". A set of credentials for a single client
identity.



cache collection

-

The set of all credential caches.



default ccache

-

A credentials cache that the Kerberos
libraries will use if no
ccache is specified by the caller. Use of the default ccache is now discouraged. Instead
applications should use selection hints to choose an appropriate client identity

5.

X.509 directory authentication services in detail?


In
cryptography
,
X.509

is an
ITU
-
T

standard for a
public key infrastructure

(PKI) and
Privilege Management Infrastructure

(PMI). X.509 specifies, amongst other

things,
standard formats for
public key certificates
,
certificate revocation lists
,
attribute
certificates
, and a
certification path validation algorithm
.

Certificates

In the X.509 system, a
certification authority

issues a certificate binding

a public key to a
particular
distinguished name

in the
X.500

tradition, or to an

alternative name

such as an
e
-
mail address

or a
DNS
-
entry.

An organization's trusted
root certificates

can be distributed to all employees so that they
can use the company PKI system. Browsers such as
Internet Explorer
,
Netscape
/
Mozilla
,
Opera
,
Safari

and
Chrome

come with root certificates
pre
-
installed, so
SSL

certificates
Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

9

from larger vendors will work instantly; in effect the browsers' developers determine
which CAs are trusted third parties for the

browsers' users

X.509 also includes standards for
certificate revocation list

(CRL) implementations, an
often neglected aspect of PKI systems. The
IETF
-
approved way of checking a
certificate's validity is the
Online Certificat
e Status Protocol

(OCSP). Firefox 3 enables
OCSP checking by default along with versions of Windows including Vista and later

Structure of a certificate

The structure foreseen by the standards is expressed in a formal language, namely
Abstract Syntax Notation One
The structure of an X.509 v3
digital certificate

i
s as follows

Certificate

o

Version

o

Serial Number

o

Algorithm ID

o

Issuer

o

Validity



Not Before



Not After

o

Subject

o

Subject Public Key Info



Public Key Algorithm



Subject Public Key

o

Issuer Unique Identifier (optional)

o

Subject Unique Identifier (optional)

o

Extensions
(optional)



...



Certificate Signature Algorithm



Certificate Signature

Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

10

Each extension has its own id, expressed as
Object identifier
, which is a set of values,
together wi
th either a critical or non
-
critical indication. A certificate
-
using system MUST
reject the certificate if it encounters a critical extension that it does not recognize, or a
critical extension that contains information that it cannot process. A non
-
critic
al
extension MAY be ignored if it is not recognized, but MUST be processed if it is
recognized

The structure of Version 1 is given in
RFC 1422

ITU
-
T introduced issuer and subject unique identifiers in version

2 to permit the reuse of
issuer or subject name after some time. An example of reuse will be when a
CA

goes
bankrupt and its name is deleted from the country's p
ublic list. After some time another
CA with the same name may register itself, even though it is unrelated to the first one.
However,
IETF

recommends that no issuer and subject names be reused. Th
erefore,
version 2 is not widely deployed in the Internet

Extensions were introduced in version 3. A CA can use extensions to issue a certificate
only for a specific purpose (e.g. only for
signing digital object
). Each extension can be
critical or non
-
critical. If an extension is critical and the system processing the certificate
does not recognize the extension or cannot process it, the system MUST reject the entire
certificate. A
non
-
critical extension, on the other hand, can be ignored while the system
processes the rest of the certificate

In all versions, the serial number MUST be unique for each certificate issued by a
specific CA

X.509 Certificate Authentication Service and Pub
lic Key Infrastructure

Certificate Authentication Service provides the
AIX®

operating system with the ability
to authenticate users using X.509 Public Key Infrastructure (PKI) certificates and to
associate certificates with processes as proof of a user's i
dentity. It provides this
capability through the Loadable Authentication Module Framework (LAMF), the same
Network security


Unit
-
3

N HARI BABU


HOD, Dept of CSE

11

extensible
AIX

mechanism used to provide DCE, Kerberos, and other authentication
mechanisms.



Overview of Certificate Authentication Service

Every user account participating in PKI authentication has a unique PKI certificate.
The certificate in conjunction with a password is use
d to authenticate the user during
login.



Certificate Authentication Service implementation

the server side of certificate
authentication service publishes certificates and
certificate revocation lists (CRLs) that it creates to an LDAP server. The client side
of certificate authentication service implements the user authentication, user
administration, and user certificate man
agement functions of certificate
authentication service.



Certificate Authentication Service planning

Certificate Authentication S
ervice (CAS) is available beginning with
AIX 5.2
. The
minimum software requirements for CAS are a DB2® server, an IBM® Directory
server, and a certificate authentication service server. All can be installed on one
system or on a combination of systems. Eac
h enterprise must determine the best
choice for their environment.



Packaging of Certificate Authentication Service

This table sh
ows the package components of the Certificate Authentication Service
(CAS).



Certificate Authentication Service installation
and configuration

The following procedures are used to install and configure the Certificate
Authentication Services (CAS).