The document discusses key concepts in public key infrastructure (PKI) including X.509 certificates, certification authorities, certificate hierarchies, and certificate extensions. It describes how X.509 certificates contain a user's public key and identification information that is digitally signed by a certification authority. Certification authorities issue and manage certificates according to PKI organization models like strict hierarchies and cross-certification. Certificate revocation lists are used to invalidate compromised certificates. The document outlines authentication protocols using digital signatures and discusses extensions that provide additional certificate information.

1. 18CS2005 Cryptography and
Network Security
Module 4
Key Management and User Authentication
X.509 certificates- Public Key infrastructure-remote user authentication
principles-remote user authentication using symmetric and asymmetric
encryption-Kerberos V5
Dr.A.Kathirvel, Professor,
DCSE, KITS
kathirvel@karunya.edu

2. X.509 Authentication Service
• part of CCITT X.500 directory service standards
– distributed servers maintaining some info database
• defines framework for authentication services
– directory may store public-key certificates
– with public key of user
– signed by certification authority
• also defines authentication protocols
• uses public-key crypto & digital signatures
– algorithms not standardised, but RSA recommended

3. X.509 Certificates
• issued by a Certification Authority (CA), containing:
– 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)
• notation CA<<A>> denotes certificate for A signed by CA

4. X.509 Certificates

5. Obtaining a Certificate
• any user with access to CA can get any
certificate from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be
placed in a public directory

6. CA Hierarchy
• if both users share a common CA then they are
assumed to know its public key
• otherwise CA's must form a hierarchy
• 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
• enable verification of any certificate from one CA by
users of all other CAs in hierarchy

7. CA Hierarchy Use

8. Certificate Revocation
• certificates have a period of validity
• may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
• CA’s maintain list of revoked certificates
– the Certificate Revocation List (CRL)
• users should check certs with CA’s CRL

9. Authentication Procedures
• X.509 includes three alternative
authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures

10. One-Way Authentication
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– integrity & originality of message
• message must include timestamp, nonce, B's
identity and is signed by A

11. Two-Way Authentication
• 2 messages (A->B, B->A) which also
establishes in addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
• reply includes original nonce from A, also
timestamp and nonce from B

12. Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables
above authentication without synchronized
clocks
• has reply from A back to B containing signed
copy of nonce from B
• means that timestamps need not be checked
or relied upon

13. X.509 Version 3
• has been recognised 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

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

15. Public Key Infrastructure
(PKI)

16. Overview
• Introduction
• Building Blocks
• Certificates
• Organization
• Conclusions

17. Introduction
In the beginning there were shared secret keys
• Early cryptographic systems had to use the
same key for encryption and decryption
• To establish an encrypted channel both
users needed to find out this key in some
secure fashion
–Limited – Users could meet and exchange the
key
–Flexible – Users could use a key server

18. Introduction
Key Exchange – User to User
• This exchange eliminates a communication channel that
could be attacked
• Limited - Users must meet all other users
– In a system with n users, number of meetings is on the
order of O(n2)
• Users must recognize each other or show proper
identification

19. Introduction
Key Exchange – Key Server
• Each user has set to up a key with the Key Server
• Key Server creates and transmits secure session keys to users
• Flexible – Users need only have a prior established key with the
Key Server
– For a system with n users only (n) meetings must occur
• Key Server takes care of the initial validation of user’s identities
KA,KS KB,KS

20. Building Blocks
• Cryptographic tools
• Putting them together
• Names
• Time
• A secure communication session

21. Building Blocks
Cryptographic Tools
• Symmetric Key Cryptography
– Encryption: SEK(M) = C
– Decryption: SDK(C) = M
– Secure as long as only communicating users know K
– Having K lets one read C
– Fast to calculate
• Public Key Cryptography
– Encryption: PEK+(M) = C
– Decryption: PDK-(C) = M
– Secure as long K- is only known by the receiver
– Having K- lets one read C, but having K+ does not
– Slow to calculate

22. Building Blocks
Cryptographic Tools
• Digital Signatures
– Sign: PEK-(H(M)) = S
– Verify: PDK+(S) = H(M)
– Reliable as long as only the signer knows K-
– Having K- allows one to sign, having K+ only allows
one to verify the signature
– Slow to calculate
– K’s + and - could just be a user’s public and private
keys

23. Building Blocks
Putting Them Together
• Symmetric cryptography is used for majority
of communications
• Public Key cryptography is used for exchanging
Symmetric keys
• Digital Signatures are used to validate Public
Keys

24. Building Blocks
Names
• A name in PKI must be unique to a user
• Assigning these names presents similar
difficulties as found in other areas of
Distributed Systems
• Without proper and well thought out
naming PKI is pretty much useless

25. Building Blocks
Time
• A PKI must know the current time
• Much of a PKI’s security relies on having an
accurate clock
• For the most part, time does not need to be
known extremely reliably and being off by a
minute will usually not be an issue

26. Building Blocks
A Secure Communications Session
• Alice and Bob wish to set up a secure
communications channel
• They use Public Key Cryptography to exchange a
Symmetric key
– Alice: Private PK = K-A, Public PK = K+A
– Bob: Private PK = K-B, Public PK = K+B
– Time T and random Symmetric Key KS
– Simplified example:
1: Alice -> Bob: PEK+B(Alice, T, K+A, PEK-A(T, KS))
2: Bob -> Alice: PEK+A(T, KS)
3: Alice <-> Bob: SEKS(Mi)

27. Certificates
• What they are
• How they are issued
• How they are distributed
• How they are revoked

28. Certificates
What they are
• The issue with building a secure session is that it
assumes that both Alice and Bob know each
others public keys
• We need some way for them to learn this
besides meeting each other (otherwise we are
in the same predicament as with Symmetric Key
exchange meetings)
• We could use a similar strategy to the Key
Server but can we do better?
This is where Certificates come in…

29. Certificates
What they are
• A Certificate is a combination of a user’s public
key, unique name, Certificate start and expiration
dates, and possibly other information
• This Certificate is then digitally signed, by some
Trusted 3rd Party, with the signature being
attached to the rest of the Certificate
• This Signed Certificate is commonly referred to as
just the user’s Certificate
• The Certificate for a user Bob, signed by signer
Tim, in essence states
“I Tim certify that this Public Key belongs to Bob”

30. Certificates
How they are issued
• The users of a PKI must place their trust in a
3rd Party to carefully verify a user’s identity
before signing his or her public key
• Each user generates their own Public-Private
Key pair and Certificate
• A user then verifies them self to the 3rd Party
and shows his or her Certificate’s content. At
this point the third party will sign the
Certificate.

31. Certificates
How they are distributed
• Users are free to distribute their signed
Certificates over any medium, public or
private, without concern
• Other users may acquire this Certificate from
any source and check the 3rd Party’s signature
for tampering
• If the signature is good then the other users
know that the 3rd Party affirms that the
Certificate belongs to the user who is listed in
the Certificate

32. Certificates
How they are Revoked
• Periodically Certificates may become compromised,
requiring a Certificate Revocation
• A Certificate Revocation message is simply a message
signed by K-i (the private version of the Certificate’s
K+i) saying that the Certificate is revoked
• A PKI will have a database of revoked Certificates (a
Certificate Revocation List, CRL) that users may
access periodically for the latest list of revoked
Certificates
• An alternative to certificate revoking is to set the
expiration time to very shortly after the issue time.
Thus every key in this system is revoked so rapidly
that we do not need to worry what may happen to
the compromised key

33. Organization
• What is “Trust”?
• How do we organize a PKI to
disseminate trust?

34. Organization
Trust
• Trust is based on real world contractual
obligations between a 3rd Party and users
• This Trusted 3rd Party is referred to as a
Certificate Authority (CA)
• In other models trust is based on personal
relationships that don’t have a contractual
basis (e.g. PGP)
• Users may allow a CA to delegate their trust
• This delegation of trust is what allows us to
build large PKI’s

35. Organization
Trust
• If Alice trusts Root CA then she trusts Bob’s
Certificate signed by Root CA
• If Alice trusts Root CA to delegate her trust to others
then she trusts Chad’s Certificate signed by Small CA
Alice
Root CA
Small CA
Bob Chad

36. Organization
Organizing a PKI
• A PKI may be organized based on a
variety of models using delegation of
trust
–Strict Hierarchy
–Networked
–Web Browser
–PGP

37. Organization
Strict Hierarchy
• All users trust Root CA
• Root CA may delegate that trust to other CA’s who in turn may
be allowed to delegate that trust
• In this way a PKI may grow without all the burden being
placed on Root CA
Alice
Root CA
Small CA
Bob Chad Dan
Smaller CA
Emily Fred

38. Organization
Networked
• The Networked model addresses what to do
when two or more PKIs wish to join together
or merge
• Two techniques
– Mesh
– Hub-and-Spoke
• We only need the Root CAs of each PKI to
participate in this model

39. Organization
Networked – Mesh
• Every Root CA signs every other Root CA’s
Certificate
• Hard to join a large numbers of CAs
Root CA3
Root CA1 Root CA2
Root CA4

40. Organization
Networked – Hub-and-Spoke
• The Root CAs come together to create the Super Root CA
• Each Root CA signs the Super Root CA’s certificate while the Super Root CA signs
each of theirs
• Easier to join large numbers of CAs
• Question becomes, Who gets to manage the Super Root CA?
Root CA3
Root CA1 Root CA2
Root CA4
Super Root CA

41. Organization
Web Browser
• A Web Browser maintains a list of trusted Root CAs
• Any Certificate signed by one of these Root CAs is trusted
• Basically a list of n Hierarchy Models
• Initial list decided on by Web Browser’s producer
alice.com bob.com chad.com dan.com
Smaller CA
emily.com fred.com
Root CA3
Root CA1 Root CA2 Root CAn
…

42. Organization
PGP
• Each user’s Certificate is signed by zero or more other users
• Certificate validity calculated from levels of trust assigned by signers
• Assigned levels (Chad)
– Implicit: User themselves – Chad
– Complete: Any Certificate signed by the user them self – Fred and Emily
• Intermediate Calculated Item
– Partial Trust: Any Certificate signed by a ‘Complete’ Certificate – Bob and Dan
• Calculated (Chad)
– Valid: Any Certificate signed by an ‘Implicit’ or ‘Complete’ level Certificates – Chad, Fred, Emily,
Dan, and Bob
– Marginally Valid: Any Certificate signed by two or more ‘Partial’ trust Certificates – Gary
– Invalid: Any Certificate signed by a ‘Marginally Valid’ or no one - Alice
Alice
Bob
Chad
Dan
Emily
Fred
Gary

43. Conclusions
• A PKI allows us to take the concept of a Key Server and
apply it to Public Keys
• It allows greater flexibility then a Key Server in that users
do not need to communicate with the Root CA every
time a Session Key is needed
• There are a vast variety of models for disseminating trust
in a PKI
• Even though PKIs look like an amazing idea, in practice
there are numerous problems implementing them on a
large scale
– Who does everyone trust?
– What format do people use?
– Security of the multitude of programs that rely on PKIs

44. Chapter 15 User Authentication
“Badges? We ain’t got no badges! We don’t
need no badges! I don’t have to show you any
stinking badges!”
—The Treasure of the Sierra Madre,
1948

45. Remote User-Authentication Principles
• The process of verifying an identity claimed
by or for a system entity
• An authentication process consists of two
steps:
• Presenting an
identifier to the
security system
Identification
step
•Presenting or generating
authentication information
that corroborates the binding
between the entity and the
identifier
Verification
step

46. Means of User Authentication
• For network-based user authentication, the most important
methods involve cryptographic keys and something the
individual knows, such as a password
Something the individual knows
• Examples include a password, a
personal identification number (PIN),
or answers to a prearranged set of
questions
Something the individual possesses
• Examples include cryptographic keys,
electronic keycards, smart cards, and
physical keys
• This is referred to as a token
Something the individual is (static
biometrics)
• Examples include recognition by
fingerprint, retina, and face
Something the individual does
(dynamic biometrics)
• Examples include recognition by
voice pattern, handwriting
characteristics, and typing rhythm
There are four general
means of authenticating a
user’s identity, which can
be used alone or in
combination

47. Mutual Authentication
• Protocols which enable communicating parties to satisfy
themselves mutually about each other’s identity and to
exchange session keys
Central to the
problem of
authenticated
key exchange are
two issues:
Confidentiality
•Essential identification and
session-key information
must be communicated in
encrypted form
•This requires the prior
existence of secret or public
keys that can be used for
this purpose
Timeliness
•Important because of the threat
of message replays
•Such replays could allow an
opponent to:
•compromise a session key
•successfully impersonate
another party
•disrupt operations by presenting
parties with messages that
appear genuine but are not

48. Replay Attacks
1. The simplest replay attack is one in which the opponent
simply copies a message and replays it later
2. An opponent can replay a timestamped message within the
valid time window
3. An opponent can replay a timestamped message within the
valid time window, but in addition, the opponent
suppresses the original message; thus, the repetition
cannot be detected
4. Another attack involves a backward replay without
modification and is possible if symmetric encryption is
used and the sender cannot easily recognize the difference
between messages sent and messages received on the
basis of content (Reflection Attack)

49. Approaches to Coping With Replay Attacks
• Attach a sequence number to each message used in an authentication exchange
– A new message is accepted only if its sequence number is in the proper order
– Difficulty with this approach is that it requires each party to keep track of the
last sequence number for each claimant it has dealt with
– Generally not used for authentication and key exchange because of overhead
– Timestamps
– Requires that clocks among the various participants be synchronized
– Party A accepts a message as fresh only if the message contains a timestamp
that, in A’s judgment, is close enough to A’s knowledge of current time
– Challenge/response
– Party A, expecting a fresh message from B, first sends B a nonce (challenge)
and requires that the subsequent message (response) received from B contain
the correct nonce value
• Binding – In all cases, cryptographic means must be used to insure that neither
cut-and-paste nor message modification is possible without detection

50. One-Way Authentication
One application for which
encryption is growing in
popularity is electronic
mail (e-mail)
• Header of the e-mail
message must be in the clear
so that the message can be
handled by the store-and-
forward e-mail protocol,
such as SMTP or X.400
• The e-mail message should
be encrypted such that the
mail-handling system is not in
possession of the decryption
key
A second requirement is
that of authentication
• The recipient wants some
assurance that the message
is from the alleged sender
See Chapter 19 on securing email

51. Remote User-Authentication Using
Symmetric Encryption
A two-level hierarchy of symmetric keys can be used
to provide confidentiality for communication in a
distributed environment
• Strategy involves the use of a trusted key distribution
center (KDC)
• Each party shares a secret key, known as a master key,
with the KDC
• KDC is responsible for generating keys to be used for a
short time over a connection between two parties and
for distributing those keys using the master keys to
protect the distribution

52. Suppress-Replay Attacks
• The Denning protocol requires reliance on clocks that
are synchronized throughout the network
• A risk involved is based on the fact that the
distributed clocks can become unsynchronized as a
result of sabotage on or faults in the clocks or the
synchronization mechanism
• The problem occurs when a sender’s clock is ahead
of the intended recipient’s clock
– An opponent can intercept a message from the sender
and replay it later when the timestamp in the message
becomes current at the recipient’s site
– Such attacks are referred to as suppress-replay attacks

53. Kerberos Introduction
• trusted key server system from MIT
• provides centralised private-key third-party
authentication in a distributed network
– allows users access to services distributed through
network
– without needing to trust all workstations
– rather all trust a central authentication server
• two versions in use: 4 & 5

54. Kerberos Introduction
• first published report identified its
requirements as:
– security
– reliability
– transparency
– scalability
• implemented using an authentication protocol
based on Needham-Schroeder

55. Kerberos 4 Overview
• a basic third-party authentication scheme
• have an Authentication Server (AS)
– users initially negotiate with AS to identify self
– AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)
– users subsequently request access to other
services from TGS on basis of users TGT

56. Kerberos 4 Overview

57. Kerberos Realms
• a Kerberos environment consists of:
– a Kerberos server
– a number of clients, all registered with server
– application servers, sharing keys with server
• this is termed a realm
– typically a single administrative domain
• if have multiple realms, their Kerberos servers
must share keys and trust

58. Kerberos Version 5
• developed in mid 1990’s
• provides improvements over v4
– addresses environmental shortcomings
• encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
– and technical deficiencies
• double encryption, non-std mode of use, session keys,
password attacks
• specified as Internet standard RFC 1510

59. Kerberos 4
• Authentication service developed as part of Project Athena at
MIT
• A workstation cannot be trusted to identify its users correctly
to network services
– 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
– Kerberos provides a centralized authentication server whose
function is to authenticate users to servers and servers to users
– Relies exclusively on symmetric encryption, making no use of public-
key encryption

60. Kerberos 4 Requirements
• The first published report on Kerberos listed
the following requirements:
•Ideally, the user should not be
aware that authentication is taking
place beyond the requirement to
enter a password
•The system should be
capable of supporting
large numbers of clients
and servers
•Should be highly
reliable and should
employ a distributed
server architecture
with one system able
to back up another
•A network eavesdropper
should not be able to
obtain the necessary
information to
impersonate a user
Secure Reliable
Transparent
Scalable

61. Kerberos Version 4
• Makes use of DES to provide the authentication service
• Authentication server (AS)
– Knows the passwords of all users and stores these in a
centralized database
– Shares a unique secret key with each server
• Ticket
– Created once the AS accepts the user as authentic; contains the
user’s ID and network address and the server’s ID
– Encrypted using the secret key shared by the AS and the server
– Ticket-granting server (TGS)
– Issues tickets to users who have been authenticated to AS
– Each time the user requires access to a new service the client applies to
the TGS using the ticket to authenticate itself
– The TGS then grants a ticket for the particular service
– The client saves each service-granting ticket and uses it to authenticate
its user to a server each time a particular service is requested

62. The Version 4 Authentication Dialogue
The lifetime associated with the
ticket-granting ticket creates a
problem:
• If the lifetime is very short (e.g., minutes), 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
A network service (the TGS or an
application service) must be able to
prove that the person using a ticket is
the same person to whom that ticket
was issued
Servers need to authenticate
themselves to users

63. Table 15.1 (page 464 in textbook)
Summary of Kerberos Version 4 Message Exchanges

66. (This table can be found on pages 467 – 468 in the textbook)

68. (page 3 of 3)

69. Kerberos Realms and Multiple Kerberi
• A full-service Kerberos environment consisting of a
Kerberos server, a number of clients, and a number
of application servers requires that:
– The 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
– The Kerberos server must share a secret key with each
server; all servers are registered with the Kerberos
server
– The Kerberos server in each interoperating realm shares
a secret key with the server in the other realm; the two
Kerberos servers are registered with each other

70. Kerberos Realm
• A set of managed nodes that share the same
Kerberos database
• The 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
• 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

71. Kerberos Principal
• A service or user
that is known to the
Kerberos system
• Identified by its
principal name
Three parts of a principal
name
A realm
name
An
instance
name
A service
or user
name

73. Differences Between Versions 4 and 5
Version 5 is intended to
address the limitations of
version 4 in two areas:
Environmental shortcomings
• Encryption system dependence
• Internet protocol dependence
• Message byte ordering
• Ticket lifetime
• Authentication forwarding
• Interrealm authentication
Technical deficiencies
• Double encryption
• PCBC encryption
• Session keys
• Password attacks

74. Table 15.3
Summary of Kerberos Version 5 Message Exchanges

75. Table 15.4
Kerberos
Version 5
Flags
(Table can be found on
page 474 in textbook)

76. Mutual Authentication
• Public-key encryption for session key
distribution
– Assumes each of the two parties is in possession of
the current public key of the other
– May not be practical to require this assumption
• Denning protocol using timestamps
– Uses an authentication server (AS) to provide public-
key certificates
– Requires the synchronization of clocks
• Woo and Lam makes use of nonces
– Care needed to ensure no protocol flaws

77. One-Way Authentication
• Have public-key approaches for e-mail
– Encryption of message for confidentiality,
authentication, or both
– The public-key algorithm must be applied
once or twice to what may be a long message
• For confidentiality encrypt message with
one-time secret key, public-key encrypted
• If authentication is the primary concern, a
digital signature may suffice

78. Federated Identity Management
• Relatively new concept dealing with the use of a
common identity management scheme across
multiple enterprise and numerous applications and
supporting many users
• Services provided include:
– Point of contact
– SSO protocol services
– Trust services
– Key services
– Identity services
– Authorization
– Provisioning
– Management

81. Key Standards
The Extensible
Markup
Language (XML)
A markup
language that
uses sets of
embedded tags
or labels to
characterize text
elements within
a document so as
to indicate their
appearance,
function,
meaning, or
context
The Simple
Object Access
Protocol (SOAP)
Enables
applications to
request services
from one
another with
XML-based
requests and
receive
responses as
data formatted
with XML
WS-Security
A set of SOAP
extensions for
implementing
message integrity
and
confidentiality in
Web services
Security
Assertion Markup
Language (SAML)
An XML-based
language for the
exchange of
security
information
between online
business partners

83. Personal Identity Verification
• User authentication based on the possession of a smart
card is becoming more widespread
– Has the appearance of a credit card
– Has an electronic interface
– May use a variety of authentication protocols
• A smart card contains within it an entire microprocessor,
including processor, memory, and I/O ports
• A smart card includes three types of memory:
– Read-only memory (ROM) stores data that does not change
during the card’s life
– Electronically erasable programmable ROM (EEPROM) holds
application data and programs; also holds data that may vary
with time
– Random access memory (RAM) holds temporary data
generated when applications are executed

85. PIV Documentation
• FIPS 201-2—Personal Identity Verification (PIV) of
Federal Employees and Contractors
– Specifies the physical card characteristics,
storage media, and data elements that make up
the identity credentials resident on the PIV card
• SP 800-73-3—Interfaces for Personal Identity
Verification
– Specifies the interfaces and card architecture for
storing and retrieving identity credentials from a
smart card, and provides guidelines for the use
of authentication mechanisms and protocols
• SP 800-76-2—Biometric Data Specification for
Personal Identity Verification
– Describes technical acquisition and formatting
specifications for the biometric credentials of
the PIV system
• SP 800-78-3—Cryptographic Algorithms and Key
Sizes for Personal Identity Verification
– Identifies acceptable symmetric and asymmetric
encryption algorithms, digital signature
algorithms, and message digest algorithms, and
specifies mechanisms to identify the algorithms
associated with PIV keys or digital signatures
• SP 800-104—A Scheme for PIV Visual Card
Topography
– Provides additional recommendations on
the PIV card color-coding for designating
employee affiliation
• SP 800-116—A Recommendation for the Use of
PIV Credentials in Physical Access Control
Systems (PACS)
– Describes a risk-based approach for
selecting appropriate PIV authentication
mechanisms to manage physical access to
Federal government facilities and assets
• SP 800-79-1—Guidelines for the Accreditation of
Personal Identity Verification Card Issuers
– Provides guidelines for accrediting the
reliability of issuers of PIV cards that collect,
store, and disseminate personal identity
credentials and issue smart cards
• SP 800-96—PIV Card to Reader Interoperability
Guidelines
– Provides requirements that facilitate
interoperability between any card and any
reader

86. PIV Credentials and Keys
• Personal Identification Number (PIN)
– Required to activate the card for
privileged operation
• Cardholder Unique Identifier (CHUID)
– Includes the Federal Agency Smart
Credential Number (FASC-N) and
the Global Unique Identification
Number (GUID), which uniquely
identify the card and the
cardholder
• PIV Authentication Key
– Asymmetric key pair and
corresponding certificate for user
authentication
• Two fingerprint templates
– For biometric authentication
• Electronic facial image
– For biometric authentication
• Asymmetric Card Authentication Key
– Asymmetric key pair and
corresponding certificate used for
card authentication
• Optional elements include the following:
• Digital Signature Key
– Asymmetric key pair & corresponding
certificate that supports document
signing and signing of data elements
such as the CHUID
• Key Management Key
– Asymmetric key pair and
corresponding certificate supporting
key establishment and transport
• Symmetric Card Authentication Key
– For supporting physical access
applications
• PIV Card Application Administration Key
– Symmetric key associated with the
card management system
• One or two iris images
– For biometric authentication

87. Table 15.5
PIV Algorithms and Key Sizes

88. Authentication
• Using the electronic credentials resident on a PIV card, the card
supports the following authentication mechanisms:
– CHUID
The cardholder is authenticated using the signed CHUID data
element on the card. The PIN is not required. This mechanism
is useful in environments where a low level of assurance is
acceptable and rapid contactless authentication is necessary
– Card Authentication Key
The PIV card is authenticated using the Card Authentication
Key in a challenge response protocol. The PIN is not required.
This mechanism allows contact (via card reader) or contactless
(via radio waves) authentication of the PIV card without the
holder’s active participation, and provides a low level of
assurance

89. Authentication
• BIO
The cardholder is authenticated by matching his or her fingerprint sample(s) to
the signed biometric data element in an environment without a human
attendant in view. The PIN is required to activate the card. This mechanism
achieves a high level of assurance and requires the cardholder’s active
participation is submitting the PIN as well as the biometric sample
– BIO-A
The cardholder is authenticated by matching his or her fingerprint sample(s) to
the signed biometric data element in an environment with a human attendant
in view. The PIN is required to activate the card. This mechanism achieves a
very high level of assurance when coupled with full trust validation of the
biometric template retrieved from the card, and requires the cardholder’s
active participation is submitting the PIN as well as the biometric sample
• PKI
The cardholder is authenticated by demonstrating control of the PIV
authentication private key in a challenge response protocol that can be
validated using the PIV authentication certificate. The PIN is required to
activate the card. This mechanism achieves a very high level of identity
assurance and requires the cardholder’s knowledge of the PIN

91. Summary
• Remote user-
authentication
principles
– Mutual authentication
– One-way authentication
• Remote user-
authentication using
symmetric encryption
– Mutual authentication
– One-way authentication
• Kerberos
– Motivation
– Kerberos V4 and V5
• Remote user-
authentication using
asymmetric encryption
– Mutual authentication
– One-way authentication
• Federated identity
management
• Identity management
• Identity federation
• Personal identity
verification
• PIV system model
• PIV documentation
• PIV credentials and keys
• authentication