CHAPTER THREE

Public Key Cryptography, Digital

Signature and Certificates

1
 Outline
• Public and Private Keys
• Public Key Cryptography
• RSA Security
• Diffie-Hellman Algorithm
• Message authentication, Security
requirements
• Digital Signature Using Public Key
• Digital Signature Using Message Digest
• Digital certificates
• Distribution of public keys
2
 Asymmetric Encryption

• When data is encrypted

with one key, the other Decrypt
Encrypt
key must be used to
decrypt the data
– And vice versa

Decrypt Encrypt

3
 Public and Private Keys
• With asymmetric encryption each user can be
assigned a key pair: a private and public key

Private key is Public key is

known only to given away to
owner the world

4
 Public and Private keys…
• Anything encrypted with
the private key can only
be decrypted with the
public key Encrypt
• And vice versa
• Since the private key is
known only to the owner,
this is very powerful…
• Overcomes the problem
of looking for secured Decrypt
channel.

5
 Public Key Cryptography…
Public key Cryptography
• One of the encryption or decryption key is made
public depends on the use of the key.
 If Abe wants to send a confidential message to Selam
 He encrypts the message using Selam’s public key
 Send the message
 Selam will then decode it using her own private key
 On the other hand, if Selam needs to make sure that a
message sent by Abe really comes from him, how can she
make that?

6
 Public Key Cryptography…
• Using digital signature
 Abe has to first encrypt a digital signature using his private
key.
 Then encrypt the message (signature included) with
Selam’s public key.
 Send the encrypted message to Selam.

 Selam decrypts the message using her private key.

 Selam then decrypts the signature using Abe’s public key.

 If successful, she insures that it comes from Abe.

7
 Public Key Cryptography and RSA
RSA

• RSA is from Rivesh, Shamir and Aldermen

• Principle: No mathematical method is yet known to efficiently
find the prime factors of large numbers.
• In RSA, the private and public keys are constructed from very
large prime numbers (consists of hundred of decimal digits)
One of the keys can be made public.
• Breaking RSA is equivalent to finding the prime factors: this is
know to be computationally infeasible. (NP-hard)
• It is only the person who has produced the keys from the
prime number can easily decrypt the messages.
8
 Asymmetric RSA
• The RSA algorithm
- Used for both public key encryption and digital signatures.
- Security is based on the difficulty of factoring large integers.

• Major Activities
- Key Generation
- Encryption
- Digital signature
- Decryption
- Signature verification

9
 Asymmetric RSA
Key Generation Algorithm
1. Generate two large random primes, p and q
2. Compute n = pq and (φ) phi = (p-1)(q-1)
3. Choose an integer e, 1 < e < φ, such that gcd(e, phi) = 1
4. Compute the secret exponent d, 1 < d < φ, such that
d = e-1 mod φ , i.e. φ divides (ed-1)
5. The public key is (n, e) and the private key is (n, d).
 Keep all the values d, p, q and φ secret
 n is known as the modulus
 e is known as the public exponent or encryption exponent
 d is known as the secret exponent or decryption exponent.

10
 Asymmetric RSA
Encryption and Decryption
Encryption
• Sender A does the following
- Obtains the recipient B's public key (n, e)
- Represents the plaintext message as a positive integer m
- Computes the ciphertext c = me mod n
- Sends the ciphertext c to B

Decryption
• Recipient B does the following
- Uses his private key (n, d) to compute m = cd mod n
- Extracts the plaintext from the message representative m
11
 Asymmetric RSA
Digital signature and signature verification
Digital signature
• Sender A does the following
- Creates a message digest of the information to be sent
- Represents this digest as an integer m between 0 and n - 1
- Uses his/her private key (n, d) to compute the signature
s = md mod n.
- Sends this signature s to the recipient, B.
Signature verification
• Recipient B does the following
- Uses sender A's public key (n, e) to compute integer v = se mod n
- Extracts the message digest from this integer
- Independently computes the message digest of the information that has been
signed
- If both message digests are identical, the signature is valid
12
 Asymmetric RSA
Key Generation example
1. Select primes p=11, q=3.
2. n = pq = 11*3 = 33
phi = (p-1)(q-1) = 10*2 = 20

3. Choose e=3
Check gcd(e, p-1) = gcd(3, 10) = 1 (i.e. 3 and 10 are relatively prime -
have no common factors except 1) and check gcd(e, q-1) = gcd(3, 2) = 1,
therefore gcd(e, phi) = gcd(e, (p-1)(q-1)) = gcd(3, 20) = 1

4. Compute d (1<d<phi) such that d = e -1 mod phi = 3-1 mod 20

i.e. find a value for d such that phi divides ed-1 (20 divides 3d-1)
Simple testing (d = 2, 3 ...) gives d = 7
Check: ed-1 = 3*7 - 1 = 20, which is divisible by phi (20).

5. Public key = (n, e) = (33, 3)

Private key = (n, d) = (33, 7)

13
 Asymmetric RSA
Encryption and Decryption example

• Given
Public key = (n, e) = (33, 3)
Private key = (n, d) = (33, 7)

Encryption
• Now say we want to encrypt the message m = 7
- c = me mod n = 73 mod 33 = 343 mod 33 = 13
- Hence the ciphertext c = 13

Decryption
• To check decryption we compute
- m = cd mod n = 137 mod 33 = 7
14
 RSA algorithm example

Typical values of e are 3, 17, and 65537 (=216+1)

15
 RSA Example - Key Setup

1. Select primes: p=17 & q=11

2. Calculate n = pq =17 x 11=187
3. Calculate ø(n)=(p–1)(q-1)=16x10=160
4. Select e: gcd(e,160)=1; choose e=7
5. Determine d: de=1 mod 160 and d < 160
Value is d=23 since 160 divides 7x23-1
6. Publish public key PU={7,187}
7. Keep secret private key PR={23,187}
16
 RSA Example 3 - En/Decryption

 sample RSA encryption/decryption is:

 given message M = 88 (nb. 88<187)
 encryption:
C = 887 mod 187 = 11
 decryption:
M = 1123 mod 187 = 88

17
 RSA
Algorithm
Summary

18
 The Security of RSA
• Approaches to attack the RSA algorithm are:
• Brute force: This involves trying all possible private keys.

• Mathematical attacks: There are several approaches, all

equivalent in effort to factoring the product of two primes.
– Factor n into its two prime factors. This enables calculation of
ø(n) = (p-1) x (q-1), which, in turn, enables determination of
d = e-1 (mod ø(n)).

– Determine ø(n) directly, without first determining p and q.

Again, this enables determination of d = e-1 (mod ø(n)).

– Determine d directly, without first determining ø(n).

19
 Speed of RSA
• In hardware, RSA is about 1000 times slower
than DES.

• Manufacturers have also implemented RSA in

smart cards; these implementations are slower.

• In software, DES is about 100 times faster than

RSA.

20
The Diffie-Hellman Algorithm for generating
a shared secret session key

• The first public key scheme was invented by Diffie and

Hellman.
• Though it could not be used to send messages, it could
establish secret keys for use in secret key
cryptosystems.
• An eavesdropper “tapping the line” would be unable to
determine what the generated key was.

21
Diffie-Hellman Key Exchange Algorithm
• a public-key distribution scheme
– cannot be used to exchange an arbitrary message
– rather it can establish a common key
– known only to the two participants
• value of key depends on the participants (and their
private and public key information)
• based on exponentiation in a finite field (modulo a
prime or a polynomial) - easy
• security relies on the difficulty of computing discrete
logarithms (similar to factoring) – hard

22
The Diffie-Hellman Algorithm for generating
a shared secret session key
• The pair of numbers (q, α) is public.
• This pair of numbers may be used for several runs of the
protocol.
• These two numbers may even stay the same for a large
number of users for a long period of time.
• Subsequently, A and B use the algorithm described below
to calculate their public keys that are then made available
by each party to the other:
– We will denote A’s and B’s private keys by XA and XB.
– And their public keys by YA and YB.
– In other words, X stands for private and Y for public.
23
The Diffie-Hellman Algorithm for generating
a shared secret session key
• A selects a random number XA from the set {1, 2, . . . , q − 2} to
serve as his/her private key.
• A then calculates a public-key integer YA that is guaranteed to exist:
YA = αXA mod q
• A makes the public key YA available to B.
• Similarly, B selects a random number XB from the set
{1, 2, . . . , q − 2} to serve as his/her private key.
• B then calculates an integer YB that serves his/her public key:
YB = αXB mod q
• B makes the public-key YB available to A.

24
The Diffie-Hellman Algorithm for generating
a shared secret session key
• A now calculates the secret key K from his/her private
key XA and B’s public key YB :

K = (YB)XA mod q

• B carries out a similar calculation for locally generating

the shared secret key K from his/her private key XB and
A’s public key YA :

K = (YA)XB mod q

25
 Diffie-Hellman Key Exchange
• shared session key for users A & B is KAB:
KAB = αxA.xB mod q
= yAxB mod q (which B can compute)
= yBxA mod q (which A can compute)
• KAB is used as session key in private-key
encryption scheme between Alice and Bob
• if Alice and Bob subsequently communicate, they
will have the same key as before, unless they
choose new public-keys
• attacker needs an x, must solve discrete log
26
 Diffie-Hellman Example
• users Alice & Bob who wish to swap keys:
• agree on prime q=353 and α=3
• select random secret keys:
– A chooses xA=97, B chooses xB=233
• compute public keys:
– yA=397 mod 353 = 40 (Alice)
– yB=3233 mod 353 = 248 (Bob)
• compute shared session key as:
KAB= yBxA mod 353 = 24897 mod 353= 160 (Alice)
KAB= yAxB mod 353 = 40233 mod 353= 160 (Bob)
27
 The Diffie-Hellman Algorithm with key
exchange

• The seemingly magical thing about the DH protocol is

that:
– an eavesdropper having access to the public keys for both A
and B would still not be able to figure out the secret key K.
– it allows two parties A and B to create a shared secret K
without either party having to send it directly to the other.

28
 The Diffie-Hellman Algorithm Security

• The difficulty of determining the secret shared key K from the

publicly available q, α , YA, and YB is sometimes referred to as
the Computational Diffie-Hellman Assumption.

• Is this enough to compute the K value? No! In order to compute

K, the eavesdropper must do either of two things:
– Raise αXA to the XB power (mod q), which he cannot do because
he does not know XB, or
– Raise αXB to the XA power (mod q), which he cannot do because
he does not know XA.

29
 The Diffie-Hellman Algorithm Security

• Even if you accept the security of DH on the basis of the diffi-

culty of solving the discrete logarithm problem, the DH protocol
possesses a number of vulnerabilities.
• If interested, see the publication “Security Issues in the Diffie-
Hellman Key Agreement Protocol” by Raymond and Stiglic for a
list of these vulnerabilities.
• One of the most serious vulnerabilities of DH is man-in-the-
middle attack.

30
Digital Signatures and Digital
Certificates

31
 Message Authentication
• Up till now, we have been concerned with protecting
message content (i.e secrecy) by encrypting the message.

• Will now consider:

– how to protect message integrity (ie protection from
modification), as well as
– confirming the identity of the sender.

• generally this is the problem of message authentication,

• In eCommerce applications it is more important than
secrecy.

32
 Message Authentication…
• Message authentication is concerned with:
– Protecting the integrity of a message
– Validating identity of originator
– Non-repudiation of origin (dispute resolution)

• Electronic equivalent of a signature on a message.

• First, we will consider the security requirements
• Then two alternative functions used:
– message encryption
– hash function

33
 Security Requirements
• In the context of communications across a network, the
following attacks can be identified:
• Disclosure: Release of message contents to any person or
process not possessing the appropriate cryptographic key.

• Traffic analysis: Discovery of the pattern of traffic between

parties.

• Masquerade: Insertion of messages into the network from a

fraudulent source.
– This includes the creation of messages by an opponent that are
supposed to come from an authorized entity.

34
 Security Requirements
• Content modification: Changes to the contents of a message,
including insertion, deletion, transposition, and modification.

• Sequence modification: Any modification to a sequence of

messages between parties, including insertion, deletion, and
reordering.

• Timing modification: Delay or replay of messages.

• Source repudiation: Denial of transmission of message by

source.

• Destination repudiation: Denial of receipt of message by

destination.

35
 Security Requirements
• disclosure Belongs to message confidentiality, and are
handled using the encryption techniques already
• traffic analysis discussed.

• The remaining requirements belong

• masquerade in the realm of message
authentication.
• content modification • This addresses the issue of ensuring
that a message comes from the
• sequence modification assumed source and has not been
altered.
• timing modification • The use of a digital signature can
also address issues of repudiation.
• source repudiation
• It may also address sequencing and
• destination repudiation timeliness.

36
 Message Encryption

• Message encryption by itself also provides a

measure of authentication.

• If symmetric encryption is used then:

– receiver know sender must have created it
– since only sender and receiver know the key used
– Encryption of a message by a sender's private key
also provides a form of authentication.

– E.g. DES,3DES,...
37
 Message Encryption…

• If public-key encryption is used:

– encryption provides no confidence of sender
– since anyone potentially knows public-key
– however if
• sender signs message using their private-key
• then encrypts with recipients public key
• have both secrecy and authentication
– E.g. RSA

38
 Authentication using session-key
• If a message is being encrypted using a session key known
only to the sender and receiver, then the message may
also be authenticated.
– since only sender or receiver could have created it
– any interference will corrupt the message
– but this does not provide non-repudiation since it is
impossible to prove who created the message
• E.g. DH

39
 Digital Signature
• Digital signatures allow the world
to verify I created a piece of data
– e.g. email, code

• Digital signatures are created by encrypting a hash

of the data with my private key
• The resulting encrypted data is the signature
• This hash can then only be decrypted by my public
key

40
 Why Digital Signatures?

• To provide Authenticity, Integrity and Non-

repudiation to electronic documents

• To use the Internet as the safe and secure

medium for any data exchange between two
users

41
 Digital Signature using pubic key
cryptography (RSA)
• RSA may be used directly as a digital signature scheme
– given an RSA scheme {(e,n), (d,n)}
• To sign a message, compute:
– s = md(mod n)
• To verify a signature, compute:
– m = se(mod n) = me.d(mod n)
• Thus know the message was signed by the owner of the
public-key.
• More commonly use a hash function to create a separate
Message Digest (MD) which is then signed.

42
 Hash Function Properties
• a Hash Function produces a fingerprint of some file/message/data
h = H(M)
– condenses a variable-length message M
– to a fixed-sized fingerprint h
-
the length of h must be at least 128 bits.
-
given M, it must be easy to calculate H(M) = h
-
given h, it must be difficult to calculate M = H-1(h)
-
given M, it must be difficult to find M’ such that H(M) = H(M’)
• Examples:
●
SNEFRU: hash of 128 or 256 bits;
●
MD4/MD5: hash of 128 bits;
●
SHA : hash of 160,256 bits.

• assumed to be public
43
 Digital Signatures – Authentication
using hash function
• Abe calculates the hash of the
message: a 128 bit value based on
Abe
the content of the message
• Abe encrypts the hash using his
private key: the encrypted hash is message
message Hash A
the digital signature.
• Abe sends the signed message to Digital Signature
Digital Signature
Kebe.
• Kebe calculates the hash of the
message
• Decrypts A with Abe’s public key. Kebe

• If hashes equal: Abe’s keys

1. hash A is from Hash B
message
Abe’s private key; =?

• 2. message wasn’t Hash A Digital Signature

modified; public private 44

 Digital Certificates
• Abe’s digital signature is useful to Kebe if:
1. Abe’s private key is not compromised – keep these safe!!!
2. Kebe has Abe’s public key

• How can Kebe be sure that Abe’s public key is really

Abe’s public key and not someone else’s?
– A third party establishes the correspondence between public
key and owner’s identity.
– Both Kebe and Abe trust this third party

The “third party” is called a Certification Authority (CA).

CA

45
 Key Distribution: Problems
• Distribution of a key is a difficult matter!

• For a symmetric cryptosystem, the initial key must be

communicated along a secured channel(?)

• For public key, we need a body that certifies the public

key is that of the party we need to communicate with

• Solution: Certification/Certificate Authority (CA) that

signs (certifies) the public key

46
 Key Management

• public-key encryption helps address key

distribution problems
• have two aspects of this:
– distribution of public keys
– use of public-key encryption to distribute secret keys

47
 Using public keys to exchange secrete
session keys
• Public key cryptography fulfills an extremely important
role in the overall design and operation of secure
computer net-works.
– because it leads to superior protocols for managing and
distributing secret session keys
– that can subsequently be used for the encryption of actual
message content using symmetric-key algorithms such as
3DES, AES, etc..

48
 Using public keys to exchange secrete
session keys…
Scenario 1
• If party A simply wants to receive all communications
confidentially
– meaning that A does not want anyone to snoop on the incoming
message traffic and
– A is not worried about the authenticity of the messages received,
• all that A has to do is to publish his/her public key in some
publicly accessible place (such as on a web page).
• Subsequently, anyone wanting to send a confidential message
to A would encrypt that message with A’s public key.
• Only A would be able to decrypt such messages.

49
 Using public keys to exchange secrete
session keys…

• If two parties A and B are sure about each other’s identity, and can be
certain that a third party will not masquerade,
– they can use a simple and direct key exchange protocol for
exchanging a secret session key. ( Scenario 2)
• In general, such protocols will not require support from any
coordinating or certificating agencies.
• The key exchange protocols are more complex for security that
provides a higher level of either one-sided or mutual authenti- cation
between two communicating parties.
• These protocols usually involve Certificate Authorities.

Scenario 3
50
 A direct key exchange protocol
(Scenario 2)
• If each of the two parties A and B has full confidence that
a message received from the other party is indeed
authentic,
• the exchange of the secret session key for a symmetric-key
based secure communication link can be carried out with a
simple protocol such as the one described below:

– Wishing to communicate with B, A generates a public/private

key pair {PUA, PRA} and
– A transmits an unencrypted message to B consisting of PUA
and A’s identifier, IDA (which can be A’s IP address).
– Note that PUA is party A’s public key and PRA the private key.
51
 A direct key exchange protocol…
• Upon receiving the message from A, B generates and stores a secret
session key KS.
• Next, B responds to A with the secret session key KS.
– This response to A is encrypted with A’s public key PUA.
– We can express this message from B to A as E(PUA, KS).
• Obviously, since only A has access to the private key PRA, only A can
decrypt the message containing the session key.
• A decrypts the message received from B with the help of the private
key PRA and retrieves the session key KS.
• A discards both the public and private keys, PUA and PRA, and B
discards PUA.
• Now A and B can communicate confidentially with the help of the
session key KS.
52
 A direct key exchange protocol…
• However, this protocol is vulnerable to the man-in-the-
middle attack by an adversary E who is able to intercept
messages between A and B.

• This is how this attack takes place:

– When A sends the very first unencrypted message consisting of
PUA and IDA, E intercepts the message. (Therefore, B never
sees this initial message.)
– The adversary E generates its own public/private key pair {PUE,
PRE} and transmits {PUE, IDA} to B.
– Assuming that the message received came from A, B generates
the secret key KS, encodes it with PUE, and sends it back to A.

53
 A direct key exchange protocol…
• This transmission from B is again intercepted by E, who for
obvious reasons is able to decode the message.
• E now encodes the secret key KS with A’s public key PUA
and sends the encoded message back to A.
• A retrieves the secret key and, not suspecting any foul
play, starts communicating with B using the secret key.
• E can now successfully eavesdrop on all communications
between A and B.

54
 Certificate Authorities for authenticating
your public key
• A certificate issued by a certificate authority (CA)
authenticates your public key.
– A certificate is your public key signed by the CA’s private key.
• A certificate assigned to a user consists of:
– The user’s public key,
– the identifier of the key owner,
– a time stamp (in the form of a period of validity), etc.,

• The whole block encrypted with the CA’s private key.

• Encryption of the block with the CA’s private key is referred
to as the CA having signed the certificate.

55
 Certificate Authorities for authenticating
your public key…
• We may therefore express a certificate issued to party A by
CA = E (PRCA, [T, IDA, PUA])
– where PRCA is the private key of the Certificate Authority,
– T the expiration date/time for the A’s public key PUA that is being
validated by the CA, and
– IDA the party A’s identifier.

• Subsequently, when party A presents his/her certificate to party B,

B can verify the legitimacy of the certificate by decrypting it with
the CA’s public key.
• Successful decryption authenticates both:
– the certificate supplied by A and
– A’s public key.
56
 Certificate Authorities for authenticating
your public key…
• Having established the certificate’s legitimacy,
– having authenticated A, and
– having acquired A’s public key,
• B responds back to A with his own certificate.
• A processes B’s certificate in the same manner as B processed A’s
certificate.
• This exchange results in A and B acquiring authenticated public
keys for each other.
• NOTE
– Each of the two parties A and B acquires the other party’s public key
not directly but through the other party’s certificate.
– For greater security, B can ask CA to verify that the certificate
received from A is currently valid, that is, it has not been revoked.
57
 Parties A and B want to establish a secure and
authenticated communication link
• Party A initiates a request for the link

58
 Using Authenticated Public Keys to Exchange a
Secret Session Key
• Having acquired the public keys, the two parties A and B then
proceed to exchange a secret session key.

Party A Party B

59
 Using Authenticated Public Keys to
Exchange a Secret Session Key…
• A uses B’s public key PUB to encrypt a message that contains A’s
identifier IDA and a nonce N1 as a transaction identifier.
• A sends this encrypted message to B.
• This message can be ex-pressed as
E (PUB, [N1, IDA])
• B responds back with a message encrypted using A’s public key
PUA, the message containing A’s nonce N1 and new nonce N2
from B to A.
• The structure of this message can be expressed as
E (PUA, [N1, N2])

60
 Using Authenticated Public Keys to Exchange a
Secret Session Key…
• Since only B could have decrypted the first message from A to B, the
presence of the nonce N1 in this response from B further assures A
that the responding party is actually B
– since only B could have decrypted the original message containing the nonce N1.

• A now selects a secret session key KS and sends B the following

message
M = E (PUB, E (PRA, KS))
• NOTE
• A encrypts the secret key KS with his/her own private key PRA before further
encrypting it with B’s public key PUB.
• Encryption with A’s private key makes it possible for B to authenticate the
sender of the secret key.

61
 Using Authenticated Public Keys to
Exchange a Secret Session Key…
• Further encryption with B’s public key means that only B will be
able to read it.
• B decrypts the message first with its own private key PRB and
then recovers the secret key by applying another round of
decryption using A public key PUA.

62
63
 The X.509 Certificate format standard for
Public Key Infrastructure
• The set of standards related to the creation, distribution,
use, and revocation of digital certificates is referred to as
the Public Key Infrastructure (PKI).
• X.509 is one of the PKI standards.
– It is this standard that specifies the format of digital certificates.
• The X.509 standard is described in the IETF document RFC 5280,
RFC 6818.
• The X.509 standard is based on a strict hierarchical organization
of the CAs in which the trust can only flow downwards.
• The CAs at the top of the hierarchy are known as root CAs.
• The CAs below the root are generally referred to as intermediate-
level CAs.
64
 Role of a PKI

• Create…
… Manage…
… Store…
… Distribute and revoke
certificates !
• For:
– Authentication, Integrity, Confidentiality, Non-
repudiation, (access control)

65
Delegation of authority

66
67
 X.509 Certificate Format
• Version Number: describes the
version of the X.509 standard to
which the certificate corresponds.
• Serial Number: This is the serial
number assigned to a certificate by
the CA.
• Signature Algorithm ID: This is the
name of the digital signature
algorithm used to sign the certificate.
(MD5,SHA)
• Issuer Name: This is the name of
the Certificate Authority that issued
this certificate.
• Validity Period: This field states the
time period during which the
certificate is valid.
• Subject Name: This field identifies
the individual/organization to which 68
the certificate was issued.
 X.509 Certificate Format
• Subject Public Key: This field
presents the public key that is
meant to be authenticated by this
certificate.
– This field also names the algorithm
used for public-key generation.
• Issuer Unique Identifier:
(optional)With the help of this
identifier, two or more different CA’s
can operate as logically a single CA.
– The Issuer Name field will be
distinct for each such CA but they
will share the same value for the
Issuer Unique Identifier.
• Subject Unique Identifier:
(optional) With the help of this
identifier, two or more different
certificate holders can act as a single
logical entity. 69
 X.509 Certificate Format
• Each holder will have a different
value for the Subject Name field
but they will share the same value
for the Subject Unique Identifier
field.
• Extensions: (optional) This field
allows a CA to add additional private
information to a certificate.
• Signature: This field contains the
signature of the CA that issued the
certificate.
– This signature is obtained by first
computing a message digest
from the rest of the fields with a
hashing algorithm like SHA-1,
– Then CA will encrypt MD using
private key Signature
70
 The X.509 Certificate format standard for Public
Key Infrastructure
• The digital representation of an X.509 certificate, described in RFC 5280, is
created by first using the following ASN.1 representation to generate a byte
stream for the certificate and converting the byte stream into a printable form
with Base64 encoding.
Certificate ::= SEQUENCE {

71
The X.509 Certificate format standard for
Public Key Infrastructure

72
 The X.509 Certificate format standard for
Public Key Infrastructure
• It is the hash of the bytestream that corresponds to what is
stored for the field TBSCertificate that is encrypted by the CA’s
private key for the digital signature that then becomes the value
of the signatureValue field.

• You may read TBSCertificate as the “To Be Signed” portion of

what appears in the final certificate.

• As to what algorithms are used for hashing and for encryption

with the CA’s private key, that is identified by the value of the
field signatureAlgorithm.

73
 The X.509 Certificate format standard for
Public Key Infrastructure
• Shown below is an example of a certificate in Base64
representation and it resides in a file whose name carries the
“.pem” suffix.

74
 The X.509 Certificate format standard for
Public Key Infrastructure
• Ordinarily you would request a CA for a certificate for your
public key.
• But that does not prevent you from generating your own
certificates for testing purposes.
openssl> req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout
test.pem -out test.cert
• Where the first argument req to openssl is for generating an X509 certificate
• You can also use OpenSSL to make your own organization a CA.
• Visit http://sandbox.rulemaker.net/ngps/m2/howto.ca.html to find out how
you can do it.

75
 Public-Key Certification
User Certificate

Serial No.
Certificate
User Database
Name & User Name
other
credentials User’s Email
Signed Address
Signed
by using
Certificate by using
CA’s
License issued
by CCA
Request CA’s User’s Publish
private
private Public Key
key
User’s key User 1 certificate
Public CA’s Name
key User 2 certificate
Certificate .
Class
Public
Public
Private Validity Web site of CA

Digital
Signature
of CA

Key pair 76
Generation
 Digital Certificates
• Types of Digital Certificates
– site certificates
• used to authenticate web servers
– personal certificates
• used to authenticate individual users
– software publishers certificates
• used to authenticate executable
– CA certificates
• used to authenticate CA’s public keys

– All certificates have the common format standard of

X.509v3

77
 s t
L a
h e
T