Public Key Certificates -

wanderooswarrenAI and Robotics

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



Network Security

An untrusted public network.

Problems: Eve eavesdrops on network packets, Eve modifies network

packets, Eve injects
messages pretending to come from Alice/Bob, ....


Data cannot be read by unintended recipients;


Data cannot be altered without detection;


Data attributed to correct originator;


A cryptographic cipher is a pair of Encrypt and Decrypt algorithms such

that given plaintext
P, encryption key K1 and decryption key

K2 then

D(K2,E(K1, P)) = P

In absence of knowledge about K2, it must be not be feasible to

recover P from the
ciphertext E(K1, P).

Given P and E(K1, P), it must not be feasible to recover K1

Note that the plaintext P can be any data, including plain te

We call E(K1, P) the ciphertext.

Symmetric/Secret key cryptography: K1 = K2;

Public key cryptography Cryptography: K1 6= K2

Secure Communication

Bob (browser) wishes to communicate securely with Alice (web server).

If Alice and Bob share a secret

symmetric encryption key KAB then

B → A : E(K
,message(eg credit card details))

and A can decrypt the message as

message = D(K

A can also use K

to send data securely to B

A → B : E(K

If B can be sure that they only other
ncipal who knows the secret key
KAB is A then he
can feel safe about sen
ding credit card details to the

However, how does A and B come to share the secret key KAB?


Suppose that A has a (encryption) pu
blic key KA and a
corresponding (decryption) private
key K



where D(K


, P)) = P and that A’s
public key is widely known.

If B knows that A’s public key is K

then B

could first propose a random
key K

and send it
securely to A using

B → A : E(K
, [K

knows that the only principal who can d
iscover his proposed secret key

is A since only
A knows

the private decryption key K

. Therefore,
after the above exchange B can be sure
that only K

is known to A.

This is a very simple example of a secure

y exchange protocol: the two
parties exchange a
series of messages,
after which they share a secret
symmetric key.

It is also a very simple variation of the SSL/TLS protocol.


The HTTPS protocol uses SSL/TLS to es
tablish a shared secret

key KAB
between a browser B
and a web
server A
. One the key exchange protocol
has completed then all subsequent
HTTP requests and

responses are
encrypted using this key.

Public Key Certificates

How does the browser B come to learn that A’s public key is

A public key certificate is a statement that is issued a
nd signed by a trusted
third party
declaring that a given principal

(eg A) owns a given public key
(eg K

This trusted third party is called a Certific
ation Authority and the CA uses
its own p
rivate key
to ‘sign’ the certificate. This signature can be co
by anyone who knows the CA’s
public key.

A browser contains the public keys of a

number of well
known CAs. When
a browser first
connects to a web
over HTTPS the server sends its
certificate, and if it is signed by a
CA that
the browser recognizes then the
browser can continue the protocol and establish
the shared key.

Msg 1

B → A


Msg 2

A → B

certificate for K

Msg 3

B → A
, [K

Msg 4

A → B

, success...)

X500 Names for X509 Certificates

We need to be able to uniquely name
principals if we are to support
universal certificates
that bind principal (identities) to their public keys.

X500: A proposed hierarchical naming

scheme. The intention was that
X500 Distinguished
Names can be use
d to give a guaranteed name for
everything in the world!





OU=organization unit,

CN=common name,

. . .

X500 DNs are used to name principals

in X509 certificates.

X509 PKI in Practice

No clear plan on how to organize X500 dir
ectory in reality: hierarchical
naming suits military
and government but
does not work for businesses or

In practice, we have just one hierarchy pe
r organiz
ation and/or have many
commercial CAs
that sign certificates for each

other and for other principals
such as UCC and for individuals.

How does Alice learn Bob’s public key?

Alice knows and trusts a number of roo
CAs: eg, verisign.

Route from
CA Alice trusts to Bob provides
certificate chain.

Some C
As only certify end
note the dan
ger of delegating to customer’s
CA (must
be trusted to delegate).

HTTPS in the Browser

We use the protocol
.com to indicate a desire f
or a
secure connection
from the browser to the web

The secure connection is successful if the c
ertificate is accepted as valid
and that web
demonstrates that it
can decrypt the key proposed by
the browser and that the Common
Name CN

in the
cert matches the domain
in the URL of the request/response.

This is a secure authentic connection.

Browser gives an indication if the secure connection is successful

Don’t embed HTTP content in HTTPS

If a page loads over HTTPS, but it includ
es some content that loads over
HTTP then

Browser (IE7/Firefox3) does not display lock and/or gives a warning

to the user.
(Safari does not detect mixed content).

However, embedded flash does not give this warning. Thus, a

programmer error
<embed src=http:

in an HTTPS web page might be
exploitable by an attacker!

→ Check whether this applies to most recent versions of Firefox/IE.

Regardless, to be safe, should avoid spec
ifying the protocol in embedded
content. <embed

Don’t embed HTTP

content in HTTPS


web page is http, however, its
HTML source contains a form

<form method= "post"


A visitor using http does not know whether

they are actually visiting the
website or some site m
asquerading as and
therefore does not know where
their login credentials are being sent.

A request to shou
ld have resulted in a re
response to
:// where the user can then enter their

credentials. The visitor should be
able t
o ’see’ that they have a secure
connection to the website they expect.

Flaws in the HTML

An old version of https://www.onsale.
com used GET for sensitive form
ibutes; on some
early browsers

the URL was not secured by SSL
(though the contents of the page were).
Regardless, its best to do a POST.

Many examples of errors in the html:

BT once had a web
server with only 40
bit crypto enabled.

Verisign once forgot
the ’s’ in an http reference to a page where user



Modern browsers like Firefox provide

a range of checks for possible
‘mistakes’. However, it
is ultimately the user’
s responsibility to ensure that
the connection is secure and to t
he right

Semantic Attacks

An attacker registers the website and obtains a valid
certificate that associates
their public key w
ith that website. Valid secure
connections can be made by the browser to

A browser
user might be confused about the domain of

Recall the GBK Chinese character set. It includes characters that l
ook like
/, ?, . and =.

Attacker owns domain and gets a cert for *

Attacker sets up a

How is the ?u interpreted?

A browser visiting this web
site under https has a valid secure

connection to (a sub
in of), however, the user of the

browser probably thinks they are visiting

Extended Validation Certificates

A conventional certificate makes few claims

about the true identity of the
owner of a

An extended validation certificate requi
res a human lawyer at the CA to
validate the identify
of the individual re
questing the certificate. These
certificates are indented for highly secure
connections such as banks.

Look at

Man in the Middle and Elsewhere Attack

Attacker sits between and user browser.

Attacker masquerades as to user browser.

User browser unknowingly connects to attacker via HTTP,

cker connects to bank via HTTPS

Attacker masquerades as to user browser.

User browser mistakenly connects to attacker via HTTPS,

Attacker connects to bank via HTTPS

Problems with accepting invalid certificates

If the browser user is niave

and is willing to a
ccept invalid certificates then
the browser user
will be subject to a man
middle attack.

Suppose that a malicious third party (bunk
.com) resides on the connection
between the
browser and a web

The browser sends an https

ct request to This is
intercepted by the man in
the midd
le who passes the request on to

The man in the middle responds
to the browser, masquerading as but with an
invalid certificate (issued to

The browser war
ns the user that the certi
ficate is invalid as its Common
Name CN does not
match that of the
URL ( that the user is

If the user accepts the invalid certificate then the man
in the middle has a
secure connection
to the user and a secur

connection to the bank and can
relay (and read/modify) data sent
between the user browser and the bank.