0% found this document useful (0 votes)
66 views87 pages

Unit 8

The document discusses key management and distribution. It covers symmetric key distribution using symmetric encryption, where keys can be manually delivered or securely transmitted between parties who already share a key. It also discusses using asymmetric encryption and a key distribution center to securely distribute symmetric keys. The document outlines how public keys can be distributed through public announcement, directories, or certificates. It describes using certificates and a public key infrastructure to authenticate public keys.

Uploaded by

test
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
66 views87 pages

Unit 8

The document discusses key management and distribution. It covers symmetric key distribution using symmetric encryption, where keys can be manually delivered or securely transmitted between parties who already share a key. It also discusses using asymmetric encryption and a key distribution center to securely distribute symmetric keys. The document outlines how public keys can be distributed through public announcement, directories, or certificates. It describes using certificates and a public key infrastructure to authenticate public keys.

Uploaded by

test
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 87

Information

Security
(3170720)
UNIT 8: KEY MANAGEMENT AND DISTRIBUTION, SYMMETRIC KEY
DISTRIBUTION USING SYMMETRIC AND ASYMMETRIC ENCRYPTIONS,
D I S T R I B U T I O N O F P U B L I C K E Y S , X . 5 0 9 C E R T I F I C AT E S , P U B L I C K E Y
INFRASTRUCTURE
R E F E R E N C E B O O K - C R Y P TO G R A P H Y A N D N E T W O R K S E C U R I T Y, P R I N C I P L E S
A N D P R A C T I C E S I X T H E D I T I O N , W I L L I A M S TA L L I N G S , P E A R S O N
CHAPTER -14
Road Map

 Key management and distribution


 Symmetric key distribution using symmetric
encryptions
 Symmetric key distribution using asymmetric
encryptions
 Distribution of public keys
 X.509 certificates
 Public key infrastructure
Key Distribution and Management
 Symmetric Key Cryptography: fast implementation, good for
encrypting large amount of data; requires shared secret key
 Asymmetric Key Cryptography: inefficient for large data; good
for authentication; no need to share a secret key
 How to share symmetric key?
 How to distribute public key?
Types of Key Distribution
 Private / Symmetric Key Distribution
 Using Symmetric Encryption
 Simple secret key – Asymmetric Encryption
 Secret Key with Confidentiality & Authentication –
Asymmetric Encryption
 Public Key Distribution
 Public Announcement
 Publically Available Directory
 Public Key Authority
 Public Key Certificate
Symmetric Key Distribution Using Symmetric
Encryption
 Objective: two entities share same secret key
 Principle: change keys frequently
 How to exchange a secret key?
1. A physically delivers key to B
2. Third party, C, can physically deliver key to A and B
3. If A and B already have a key, can securely transmit new key
to each other, encrypted with old key
4. If A and B have secure connection with third party C, C can
securely send keys to A and B
Symmetric Key Distribution Using Symmetric
Encryption
 Option 1 and 2: manual delivery; feasible if number of entities is
small (link encryption)
 Option 3: requires initial distribution of key; discovery of initial
key releases all subsequent keys.
 Option 3 is a possibility for either link encryption or end-to-end
encryption, but if an attacker ever succeeds in gaining access to
one key, then all subsequent keys will be revealed.
 Option 4: requires initial distribution of key with C; practical for
large-scale systems (end-to-end encryption)
 Option 4, key distribution center is responsible for distributing
keys to pairs of users (hosts, processes, applications) as needed.
Symmetric Key Distribution Using Symmetric
Encryption
 Link Encryption
⁻ Encrypt data over individual links in network
⁻ Each link end-point shares a secret key
⁻ Decrypt/Encrypt at each device in path
⁻ Requires all links/devices to support encryption
 End-to-End Encryption
⁻ Encrypt data at network end-points (e.g. hosts or
applications)
⁻ Each pair of hosts/applications share a secret key
⁻ Does not rely on intermediate network devices
How many key need to be exchanged?

 Link-level encryption?
 20
 End-to-end encryption between hosts?
 If n host then key required = n(n-1)/2 = 10(9)/2 = 45
 End-to-end encryption between applications?
 Each application has key . If 5 applications on every host , how many ? (end
to end )
 5 * 45 =225 key (if Application A can communicate with only application A
on another host )
 (50 *49 )/2 =1225 (if Application A can communicate with any application
on another host )
Key Distribution Centre
 Key distribution for symmetric keys by a central server (KDC):
- fixed number of distributions (for given n)

Each user must share a unique key with the key


distribution center for purposes of key distribution.
Use of Key Distribution Centre
 Key Distribution Centre (KDC) is trusted third party
 Typically have a hierarchy of keys (minimum two level of keys)
 Session key
⁻ temporary key
⁻ used for encryption of data between users
⁻ for one logical session then discarded
 Master key
⁻ used to encrypt session keys (session keys are transmitted in
encrypted form
⁻ shared by user & key distribution center (there is a unique
master key that it shares with the key distribution center.)
 If there are N entities that wish to communicate in pairs, then N(N-
1)/2 session key and N master key (one for each user) required.
 Master keys can be distributed in some non-cryptographic way,
such as physical delivery.
Use of Key Distribution Centre
End-systems: A and B, identified by
Key Distribution Scenario IDA and IDB
Master keys: Ka, Kb
Session key (between A and B): Ks
Nonce values: N1, N2
E.g. timestamp, counter, random
value
Must be different for each request
Must be difficult for attacker to
guess
Key Distribution Scenario
1. A issues a request to the KDC for a session key
 Nonce is also sent
 Nonce includes identities of communicating parties and a
unique value
2. KDC sends a response encrypted with A’s secret key KA
 It includes one time session key KS
 Original request message, including the nonce
 Message also includes KS and ID of A encrypted with KB
intended for B
3. A stores KS and forwards information for B i.e., E [KB, [KS||IDA]]
4. B sends a nonce to A encrypted with KS
5. A responds by performing some function on nonce like
incrementing
Symmetric Key distribution issue
Hierarchical Key Control
 Not suitable that a single KDC is used for all the users
 Hierarchies of KDC’s required for large networks
 A single KDC may be responsible for a small number of users since it shares
the master keys of all the entities attached to it
 If two entities in different domains want to communicate, local KDCs
communicate through a global KDC
 Reduces effort in key distribution; limits damage if local KDC is compromised
Session key life time

 Shorter lifetime is more secure; but increases overhead of


exchanges
 Connection-oriented protocols (e.g. TCP): new session key for
each connection
 Connection-less protocols (e.g. UDP/IP): change after fixed period
or certain number of packets sent
A transparent key control Scheme
 Use of automatic key distribution on behalf of users, but must
trust system
Automatic Key Distribution
1. Host sends packet requesting connection.
for Connection-Oriented
2. Security service buffers packet; asks KDC Protocol
for session key.
3. KDC distributes session key to both
hosts.
4. Buffered packet transmitted.
Decentralized key control
 KDCs need to be trusted and
protected
 This can be avoided by the
use of decentralized key
distribution (Alternative that
doesn't rely on KDC)
 Decentralized approach
requires that each node be
able to communicate in a
secure manner i.e. Each end-
system must manually
exchange n – 1 master keys
(Km) with others
Decentralized key control
 A session key may be established with the following sequence of
steps.
1. A issues a request to B for a session key and includes a nonce, N1.
2. B responds with a message that is encrypted using the shared master key.
The response includes the session key selected by B, an identifier of B, the
value f(N1), and another nonce, N2.
3. Using the new session key, A returns f(N2) to B.
Each node must maintain at most (n - 1) master keys, as many session keys
as required may be generated and used.  cryptanalysis is difficult
Controlling Key Usage
 Define different types of session keys on the basis of use, such as
 Data-encrypting key, for general communication across a network
 PIN-encrypting key, for personal identification numbers (PINs) used
in electronic funds transfer and point-of-sale applications
 File-encrypting key, for encrypting files stored in publicly accessible
locations
 This information can be represented using 8 bit tag (makes use of
the extra 8 bits in each 64-bit DES key ) or control vector.
 Tag is not feasible due to following
 The tag length is limited to 8 bits, limiting its flexibility and
functionality.
 Because the tag is not transmitted in clear form, it can be used only at
the point of decryption, limiting the ways in which key use can be
controlled.
Controlling Key Usage
The control vector is
cryptographically coupled with
the key at the time of key
generation at the KDC.
1. The control vector is passed
through a hash function that
produces a value whose
length is equal to the
encryption key length.
2. The hash value is then
XORed with the master key
to produce an output that is
used as the key input for
encrypting the session key

Use of the control vector has two advantages over use of an 8-bit tag.
First, there is no restriction on length of the control vector, which enables arbitrarily
complex controls to be imposed on key use.
Second, the control vector is available in clear form at all stages of operation. Thus,
control of key use can be exercised in multiple locations.
Symmetric Key Distribution Using
Asymmetric Encryption
Symmetric Key Distribution Using Asymmetric
Encryption
 Asymmetric encryption generally too slow for encrypting large
amount of data hence they are almost never used for the direct
encryption of sizable block of data, but are limited to relatively
small blocks.
 Common application of asymmetric encryption is exchanging secret
keys
 Three examples:
1. Simple Secret Key Distribution
2. Secret Key Distribution with Confidentiality and Authentication
3. Hybrid Scheme: Public-Key Distribution of KDC Master Keys
Simple Key Distribution
Simple Key Distribution
 Simple: no keys prior to or after communication
 Provides confidentiality for session key
 Subject to man-in-the-middle attack
 Only useful if attacker cannot modify/insert messages
Simple Key Distribution
 Insecure against an adversary who can intercept messages and then either relay the
intercepted message or substitute another message.
 Such an attack is known as a man-in-the-middle attack.
Simple Key Distribution
Secret Key Distribution with Confidentiality and
Authentication
 Provides both confidentiality and authentication in exchange of
secret key It is assumed that A and B have exchanged public keys
Secret Key Distribution with Confidentiality and
Authentication
Hybrid Key Distribution
 Retain Use Key Distribution Center (KDC)
 Share secret master key with user
 Distributes session key using master key
 Use public-key distribution to distribute master key – efficient
method to deliver master key rather than manual delivery
 The addition of a public-key layer provides a secure, efficient means
of distributing master keys.
 This is an advantage in a configuration in which a single KDC serves
a widely distributed set of users.
 Rationale
 Performance
 Backward compatibility - The hybrid scheme is easily overlaid on
an existing KDC scheme with minimal disruption or software
changes
Distribution of Public key
Distribution of Public Key

 By design, public keys are made public


 Issue: how to ensure public key of A actually belongs to A (and not
someone pretending to be A)
 Four approaches for distributing public keys
1. Public announcement
2. Publicly available directory
3. Public-key authority
4. Public-key certificates
Public Announcement
 Make public key available in open forum: newspaper, email to
group, website, conference, . . .
 Problem: anyone can announce a key pretending to be another user

Uncontrolled Public-Key Distribution


Public Announcement
 Users distribute public keys to recipients or broadcast to community
at large
 eg. append PGP(pretty good privacy) keys to email messages or
post to news groups or email list
 major weakness is forgery
 anyone can create a key claiming to be someone else and
broadcast it
 until forgery is discovered can masquerade as claimed user
Public available directory
 A greater degree of security can be achieved by maintaining a
publicly available dynamic directory of public keys.
 Maintenance and distribution of the public directory would have
to be the responsibility of some trusted entity or organization
 All users publish keys in central directory
 Users must provide identification when publishing key
Public available directory
 directory must be trusted with properties:
⁻ contains {name, public-key} entries for each participant
⁻ participants register public key securely with directory.
Registration would have to be in person or by some form of
secure authenticated communication
⁻ participants can replace key at any time
⁻ directory can be accessed electronically - For this purpose,
secure, authenticated communication from the authority to the
participant is mandatory.
Public available directory
 This scheme is clearly more secure than individual public
announcements but still has vulnerabilities.
 If an adversary succeeds in obtaining or computing the private key
of the directory authority, the adversary could authoritatively pass
out counterfeit public keys and subsequently impersonate any
participant and eavesdrop on messages sent to any participant.
 Another way to achieve the same end is for the adversary to tamper
with the records kept by the authority
Public key Authority
 Improve security by tightening control over distribution of keys
from directory
 Has properties of directory
 Assume each user has already security published public key at
authority; each user knows authorities public key but only
authorities know his private key
 Does require real-time access to directory when keys are needed
Public key Authority

• First 5 messages are for


key exchange;
• last 2 are authentication
of users
• Although 7 messages,
public keys obtained
from authority can be
cached
• Problem: authority can
be bottleneck
• Alternative: public-key
certificates
Public key Authority
Public key Authority
Public key Certificate
 Assume public keys sent to Certificate Authority (CA) can be
authenticated by CA; each user has certificate of CA
Public key Certificate
 Assume public keys sent to CA can be authenticated by CA; each
user has certificate of CA
Public key Certificate
Public key Certificate
Public key Certificate
 certificates allow key exchange without real-time access to public-
key authority
 a certificate binds identity to public key
 usually with other info such as period of validity, rights of use
etc
 with all contents signed by a trusted Public-Key or Certificate
Authority (CA) i .e. Only the certificate authority can create and
update certificates.
 Any participant can read a certificate to determine the name and
public key of the certificate’s owner.
 Any participant can verify that the certificate originated from the
certificate authority and is not counterfeit
 Any participant can verify the currency (expiry date) of the
certificate
Exchanging of Public key certificate
 A certificate is the ID and public-key of a user signed by CA
 CA = E(PRauth; [T|| IDA || PUa])
 Timestamp T validates currency of certificate
(expiration date)
Public key Certificate
Verifying Public Key certificate
Public key Certificate

Common format for certificates is X.509 standard (by ITU)


S/MIME (secure email)
IP security (network layer security)
SSL/TLS (transport layer security)
SET (e-commerce)
What is inside a digital certificate?
X.509 certificates

X.509 is a standard format for public key certificates, digital


documents that securely associate cryptographic key pairs
with identities such as websites, individuals, or
organizations.
It is used in variety of application such as IP Security, SSL/TSL
and S/MIME.
X.509 defines a framework for the provision of
authentication services by the X.500 directory to its users.
The directory may serve as a repository of public-key
certificates.
Each certificate contains the public key of a user and is
signed with the private key of a trusted certification
authority.
X.509 certificates

X.509 is based on the use of public-key cryptography and


digital signatures.
The standard does not dictate the use of a specific algorithm
but recommends RSA.
The digital signature scheme is assumed to require the use
of a hash function.
Public Key Certificate Use
Public Key Certificate Use
X.509 Formats
X.509 Format

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 parameter
X.509 Format

Issuer name: X.500 name of the CA that created and signed


this certificate.

Period of validity: Consists of two dates: the first and last on


which the certificate is valid
X.509 Format

Subject name: The name of the user to whom this certificate


refers.

Note: the Serial Number shown in


this subject field is a Nevada business
identification number, not the serial
number of the certificate itself.
X.509 Format

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
X.509 Format

Optional Field

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.
X.509 Format

At the end of certificate

Signature: Covers all of the other fields of the certificate; it


contains the hash code of the other fields encrypted with the
CA’s private key
X.509 Format

The standard uses the following notation to define a


certificate:
CA << A >> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}
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
V = version of the certificate
SN = serial number of the certificate
AI = identifier of the algorithm used to sign the certificate
CA = name of certificate authority
UCA = optional unique identifier of the CA
A = name of user A
UA = optional unique identifier of the user A
Ap = public key of user A
TA = period of validity of the certificate
CA hierarchy

If both users share a common CA then they are assumed to


know its public key.
If all users subscribe to the same CA, then there is a common
trust of that CA.
All user certificates can be placed in the directory for access by
all users.
In addition, a user can transmit his or her certificate directly to
other users.
If users are belongs to different CA then CA’s must form hierarchy.
Use certificate linking members of hierarchy to validate other CA’s
Each CA has certificate for client (forward) and parent
(backward)
Each client trust on parents certificates.
Enable verification of any certificate from one CA by users of all
other CAs in hierarchy.
CA hierarchy

Alice’s CA is Cathy; Bob’s CA is Dan; how can Alice validate


Bob’s certificate?
Dan<<Bob>>
Cathey<<Alice>> (forward)
(forward) Cathey Dan DAN <<Cathey>>
Cathey <<Dan>> (CA) (CA) (backward)
(backward)

Alice Bob
(client) (client)
Alice obtains Cathy<<Dan>>
Alice validate Cathy<<Dan>>
Alice use Cathy<<Dan>> to validate Dan<<Bob>>

Signature chain : Cathy<<Dan>> Dan<<Bob>>


CA hierarchy

User A can acquire the following certificates


from the directory to establish a certification
path to B:
X <<W >> W <<V>> V << Y >>Y << Z>> Z << B >>
Certificate Revocation

Each certificate includes a validity period


 A new certificate is issued by CA just
before it expires
Also needs to revoke a certificate before it
expires,
 If the user’s private key is compromised,
 The user is no longer certified by the CA
 The CA’s certificate is compromised
Certificate Revocation List (CRL)
 Each CA maintains a CRL of all revoked
but no expired certificates
 Each CRL in the DS is signed by the issuer
and includes the issuer’s name, creation
date, date of the next CRL to be issued,
an entry for each revoked certificate
(serial numbers)
X.509 version 3

It has been recognized that additional information is needed in a


certificate
 email/URL, policy details, usage constraints
rather than explicitly naming new fields defined a general
extension method
extensions consist of:
 extension identifier
 criticality indicator
 extension value
X.509 version 3: Certificate Extensions

key and policy information


 convey info about subject & issuer keys, plus indicators of
certificate policy
certificate subject and issuer attributes
 support alternative names, in alternative formats for certificate
subject and/or issuer
certificate path constraints
 allow constraints on use of certificates by other CA’s
Public Key Infrastructure (PKI)
A Public Key Infrastructure is an Infrastructure to support
and manage Public Key-based Digital Certificates
Public Key Infrastructure (PKI)

A public key infrastructure (PKI) is a set of roles, policies,


hardware, software and procedures needed to create, manage,
distribute, use, store and revoke digital certificates based on
asymmetric cryptography.
The principal objective for developing a PKI is to enable secure,
convenient, and efficient acquisition of public keys.
X509 Digital Certificates standard
Standards defined by IETF, PKIX WG:
http://www.ietf.org/

… however X509 is not the only approach


Public Key Infrastructure X.509 (PKIX)
End entity: A generic term
used to denote end users,
devices (e.g., servers,
routers), or any other entity
that can be identified in the
subject field of a public-key
certificate.

Certification authority (CA): The


issuer of certificates and
(usually) certificate revocation
lists (CRLs).

CRL issuer: An optional


component that a CA can
delegate to publish CRLs.
Public Key Infrastructure X.509 (PKIX)
Registration authority (RA):
An optional component that
can assume a number of
administrative functions from
the CA.
Basic tasks
• Accept and verify
registration info about
new users
• Face-to-Face Registration
• Remote Registration
• Automatic Registration

Repository: A generic term


used to denote any method
for storing certificates and
CRLs so that they can be
retrieved by end entities.
PKIX Management Functions

PKIX identifies a number of management functions that potentially


need to be supported by management protocols.
Some of the functions are
Registration:
 This is the process whereby a user first makes itself known to a
CA (directly or through an RA), prior to that CA issuing a
certificate or certificates for that user.
 Registration begins the process of enrolling in a PKI.
Registration usually involves some offline or online procedure
for mutual authentication.
PKIX Management Functions
Initialization:
 Before a client system can operate securely, it is necessary to install
key materials that have the appropriate relationship with keys stored
elsewhere in the infrastructure.
 For example, the client needs to be securely initialized with the
public key and other assured information of the trusted CA(s), to be
used in validating certificate paths.
Certification: This is the process in which a CA issues a certificate for a
user’s public key, returns that certificate to the user’s client system,
and/or posts that certificate in a repository.
Cross certification: Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a certificate
issued by one CA to another CA that contains a CA signature key
used for issuing certificates.
PKIX Management Functions

Key pair recovery: Key pairs can be used to support digital


signature creation and verification, encryption and decryption, or
both. Key pair recovery allows end entities to restore their
encryption/decryption key pair from an authorized key backup
facility.
Key pair update: All key pairs need to be updated regularly (i.e.,
replaced with a new key pair) and new certificates issued. Update
is required when the certificate lifetime expires and as a result of
certificate revocation.
Revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation. Reasons for
revocation include privatekey compromise, change in affiliation,
and name change.
PKIX Management Protocols

The PKIX working group has defines two alternative management


protocols between PKIX entities that support the management
functions
certificate management protocols (CMP)
certificate management messages over CMS (CMC) (CMS refers
cryptographic message syntax)
CMC is built on earlier work and is intended to leverage
existing implementations.
Session keys are transmitted after being encrypted by
A : make-shift keys
B : temporary keys
C : master keys
D : section keys

if end to end connection is done at a network or IP level, and if there are N


hosts, then what is the number of keys required?
A : N(N-1)/2
B:N
C : N(N+1)/2
D : N/2

For a network with N nodes, how many master keys are present?
A : N(N-1)/2
B:N
C : N(N+1)/2
D : N/2
Communication between end systems is encrypted using a key, often known
as
A : temporary key
B : section key
C : line key
D : session key

The ________ method provides a one-time session key for two parties.
A) Diffie-Hellman
B) RSA
C) DES
D) AES
Which one of the following is not a public key distribution means?
a) Public-Key Certificates
b) Hashing Certificates
c) Publicly available directories
d) Public-Key authority

Which of the following public key distribution systems is most secure?


a) Public-Key Certificates
b) Public announcements
c) Publicly available directories
d) Public-Key authority

Which systems use a timestamp?


i) Public-Key Certificates
ii) Public announcements
iii) Publicly available directories
iv) Public-Key authority
a) i) and ii)
b) iii) and iv)
c) i) and iv)
d) iv) only
Which of these systems use timestamps as an expiration date?
a) Public-Key Certificates
b) Public announcements
c) Publicly available directories
d) Public-Key authority

Which system uses a trusted third party interface?


a) Public-Key Certificates
b) Public announcements
c) Publicly available directories
d) Public-Key authority

Publicly Available directory is more secure than which other system?


a) Public-Key Certificates
b) Public announcements
c) Public-Key authority
d) None of the mentioned

Extensions were added in which version?


a) 1
b) 2
c) 3
d) 4
The subject unique identifier of the X.509 certificates was added in which version?
a) 1
b) 2
c) 3
d) 4
Which of the following is not an element/field of the X.509 certificates?
a) Issuer Name
b) Serial Modifier
c) Issuer unique Identifier
d) Signature

Suppose that A has obtained a certificate from certification authority X1 and B has
obtained certificate authority from CA X2. A can use a chain of certificates to obtain B’s
public key. In notation of X.509, this chain is represented in the correct order as –
a) X2 X1 X1 B
b) X1 X1 X2 A
c) X1 X2 X2 B
d) X1 X2 X2 A
Certificates generated by X that are the certificates of other CAs are Reverse
Certificates.
a) True
b) False
It is desirable to revoke a certificate before it expires because
a) the user is no longer certified by this CA
b) the CA’s certificate is assumed to be compromised
c) the user’s private key is assumed to be compromised
d) all of the mentioned

CRL stands for


a) Cipher Reusable List
b) Certificate Revocation Language
c) Certificate Revocation List
d) Certificate Resolution Language

Which of the following is not a part of an Extension?


a) Extension Identifier
b) Extension value
c) Criticality Indicator
d) All of the mentioned constitute the Extension

The criticality indicator indicates whether an extension can be safely ignored.


a) True
b) False
“Conveys any desired X.500 directory attribute values for the subject of this
certificate.”
Which Extension among the following does this refer to?
a) Subject alternative name
b) Issuer Alternative name
c) Subject directory attributes
d) None of the mentioned

How many handshake rounds are required in the Public-Key Distribution


Scenario(public key authority)?
a) 7
b) 5
c) 3
d) 4

A total of seven messages are required in the Public-Key distribution scenario.


However, the initial five messages need to be used only infrequently because both A
and B can save the other’s public key for future – a technique known as ____
a) time stamping
b) polling
c) caching
d) squeezing
Public key Authority

• First 5 messages are for


key exchange;
• last 2 are authentication
of users
• Although 7 messages,
public keys obtained
from authority can be
cached
• Problem: authority can
be bottleneck
• Alternative: public-key
certificates
X.509 certificate recommends which cryptographic algorithm?
a) RSA
b) DES
c) AES
d) Rabin

The period of validity consists of the date on which the certificate expires.
a) True
b) False

Certificate extensions fall into 3 categories. Which one of the following is not a
Certificate extensions category?
a) Subject and Issuer attributes
b) Key and Policy information
c) Certification path constraints
d) All of the above are Certificate extensions categories

How many functions are involved in the PKIX architectural model?


a) 3
b) 5 The 7 functions are: Registration, Initialization, Certification, Key pair
c) 6 recovery, Key pair update, Revocation request and Cross certification.
d) 7
CMP stands for
a) cipher message protocol
CMP stands for certificate management protocol
b) cipher management protocol
c) certificate message protocol
d) none of the mentioned

CMS stands for


a) cipher message syntax
b) certificate message session
c) cryptographic message syntax
d) none of the mentioned

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy