Evolving Role of PKIs

in Facilitating
Trust over the Internet
Vishwas Patil
Senior Research Scientist, IIT Bombay

(joint work with Prof. RK Shyamasundar, IIT Bombay)

Outline
1) Role of a PKI

2) Retrofitting done to PKI since its inception

3) Security & Privacy considerations

4) Alternative efforts: pros & cons

5) Summary: Should there be a singular technology to manage Trust?

Role of a PKI
PKI - Public Key Infrastructure
A set of protocols responsible to:

1) Create
2) Store
3) Distribute
4) Revoke

digital certificates.

In 1988, ITU-T released the X.509 standard outlining the set of roles, policies,
hardware, software and procedures needed to manage certificates.
PKI - Digital Certificate
Digital certificates are by far the most widely used technique to safeguard
electronic communications and transactions.

CA⟨⟨AMAZON⟩⟩
PKI - Components
Observation
Observation
Natural Entity Legal/Virtual Entity

Limited Jurisdiction Global (Internet-wide) Jurisdiction

Govt. issued credentials Digital Representation/Encapsulation

Indian Driving License EV certificate obtained using DL

We do not have a uniform, global criteria for
identity representation.

And we are building digital identities for a

global scale
PKI - Components
Certificate Chain / Path
PKI acts as a Trust Anchor
PKI acts as a Trust Anchor
PKI CA acts as a Trust Anchor
PKI CA acts as a Trust Anchor

Org3
PKI CA acts as a Trust Anchor

Root2

Org3
PKI CA acts as a Trust Anchor

Root2

Org3
Cross Certification (Trust Transition)
Security has a UI/UX Problem
● Secure connection = Green
● Insecure = Red
● Neither instance shows the details
behind the decision
● Once trusted, always trusted
(intermediate nodes in a trust
chain/path)
In X.509, trust decisions are binary
Authentication is the primary objective
Types of PKI Deployments (public, private)
Digital Certificate (Key) as a Credential

Banking

Enterprise WiFi

Satellite TV

Telecom
Authentication as Implied Authorization
PKI - Issues
1) Create (duration, CSR, validation, …)
2) Store (Key management)
3) Distribute (CRLs)
4) Revoke (Pinning, Stapling)
Alternative PKIs
● PGP (Pretty Good Privacy)

● SPKI (Simple PKI)

● SDSI (Simple Distributed Security Infrastructure)

CA⟨⟨AMAZON-Key⟩⟩ : Public-key of Amazon

AMAZON : {Key1, Key2, Key3, India, EU, USA, AWS}

CA⟨⟨AMAZON⟩⟩ : Public-keys of Amazon

Top-down vs Bottom-up
Retrofittings done to the PKI
X.509 Versions
X.509 Versions (Current version is V3)

X. 509 v3 extensions provide for the association of additional attributes with users
or public keys.

Each extension, identified by its OID (Object Identifier), is marked as “Critical” or

“Non-Critical,” and includes the extension-specific data.
PKI - Digital Certificate
Digital certificates are by far the most widely used technique to safeguard
electronic communications and transactions.

CA⟨⟨AMAZON⟩⟩
Wildcard Certificate
Certificate Pinning/Stapling
Certificate and Keys are hard coded and not checked for revocation!

Mobile apps

Hardware devices

IoTs

Proof Carrying Codes

…
Trusted Lists Initiative in EU
Trusted Lists
 EuroPKI 2009

CA⟨⟨AMAZON-Key⟩⟩

CA⟨⟨AMAZON⟩⟩
Security & Privacy considerations
DigiNotar CA compromised, 2011
Certificate Transparency
RFC 6962

Useful in keeping track of certificate

issuance

Self-signed certification logs are not

submitted to public CT servers
Signed Certificate Timestamp + OCSP
Other PKI Security Proposals
DANE (DNS-based Authentication of Named Entities)
● DANE allows a domain owner to specify which CA is allowed to issue
certificates for a particular resource, which solves the problem of any CA
being able to issue certificates for any domain.

● DANE needs the DNS records to be signed with DNSSEC for its security
model to work.

● However, DNSSEC is not yet widely deployed protocol.

Perspectives
● Perspectives is a decentralized approach to securely identifying Internet
servers.
● It automatically builds a database of server identities using lightweight probing
by network notaries - servers located at multiple vantage points across the
Internet.
● Each time a user connects to a secure website, Perspectives compares the
site’s certificate with network notary data, and warns if there is a mismatch.
● Perspectives prevents man-in-the-middle attacks, and lets users use
self-signed certificates, and helps them trust that their connections really are
secure.
Convergence
● Convergence is an extension of Perspectives with additional guarantees from
DNSSEC/DANE initiative.
● It is a method of using multi-path probing to establish a domain identity.
Convergence clients verify a site’s certificate by comparing it to the
certificates obtained by trusted notaries that have accessed the target site via
different network paths.
● By comparing the certificates, Convergence can probabilistically detect the
presence of a MitM attack, with increasing confidence as the notary set’s
network path diversity increases.
Convergence (contd.)

● This procedure replaces traditional signature verification in multi-path probing

systems; hence, even when a site’s certificate was issued by a CA,
Convergence need not trust that CA’s public key in order to validate the
certificate.
● Convergence offers the property of trust agility for the end user. Trust agility is
comprised of two properties: first, the ability to re-evaluate trust decisions at
anytime without repercussion; second, an ability for each individual to select
their own trust anchors.
MECAI (Multiple Endorsing Certificate Authority
Infrastructure)
MECAI doesn’t introduce a new set of Authorities, it rather expects additional
contributions from the existing CAs.
CAs are expected to act as Web notaries, similar to what has been already
proposed by other projects, such as the Perspectives Add-On for Mozilla Firefox,
or as part of the Convergence project.
A web notary shall be one or multiple servers that are run by a CA.
A web notary is expected to make statements about facts that can be discovered
on the web.
A client connecting to a server will receive the server’s certificate as part of the
TLS handshake.
MECAI (contd.)
A client could contact a notary, and ask the notary for the server certificate that
can be obtained from the Notary’s perspective, and send this information to the
client. The client can compare the perspectives, they should be identical.

A MITM will need to use a different certificate that the MITM controls, in order to
read and/or manipulate the data exchanged.

If the connection between client and server is influenced by a MITM, then the
certificates seen will be different based on the perspectives.

If the information returned by the notary is different than the information seen by
the client, then the client probably shouldn’t trust the information presented by the
server
Trusted-Third-Party is a Persistent Witness!
● OCSP requires a check on validity of a digital certificate before its usage
● This check leaves a log at the OCSP server about an interested party
(requester) trying to contact/authenticate another entity

● The OCSP logs at CRL servers have end-user privacy violation potential
● The recent Certificate Transparency initiative exposed identifiers of internal
resources of organizations that were supposed to be private.
Sovereign Keys
● The Sovereign Keys design allows clients and servers to use cryptographic
protocols without having to depend on any third parties after the moment the
server creates a Sovereign Key.
● Sovereign Keys are created by writing to a semi-centralized, verifiably
append-only data structure.
● The main requirement for being able to do this is that the requesting party
controls a CA-signed certificate for the relevant domain, or uses a
DNSSEC-signed key to show that they control that domain.
Sovereign Keys (contd.)
● Master copies of the append-only data structure are kept on machines called
”timeline servers”.
● There is a small number, around 10-20, of these.
● The level of trust that must be placed in them is very low, because the
Sovereign Key protocol is able to cryptographically verify the important
functions they perform.
● Sovereign Keys are preserved so long as at least one server has remained
good.
Alternative efforts: pros & cons
Authentication & Authorization (Expressive+Effective)
● X.509
● PGP
● SPKI/SDSI

● Kerberos
● SSO: OAuth, OpenID
● Policy languages: SAML, XACML

● Evolving space
Authentication as a Service
Recent advancements in blockchain technology now allow every public key to
have its own address, which is called a decentralized identifier (DID).

● Hyperledger Indy: A distributed ledger that provides tools, libraries, and

reusable components for creating and using independent digital identities.
● Sovrin: The Sovrin Network is the first public-permissioned blockchain
designed as a global public utility exclusively to support self-sovereign identity
and verifiable claims.
● W3C DID & VC: A verifiable credential can represent all of the same
information that a physical credential represents.
Think of Privacy Implications with Open Ledgers
 Sadhana, 2005

flexi-ACL

A framework to
encapsulate, evaluate
credentials provided by
various trusted parties
and enforce them
dynamically.
flexi-ACL Typical Structure
flexi-ACL Rule Examples
flexi-ACL Rule Block
Recap
1. We do not have a uniform, global criteria for identity representation.

2. And we are building digital identities for a global scale

3. In X.509, trust decisions are binary

4. Authentication is the primary objective of X.509 PKI

5. Authentication as an implied type of authorization is not flexible /

dynamic
Should there be a singular technology to
manage Trust over the Internet?
Building a Dynamic Trust Management System
 Thank you.

[email protected]
 Security measures

In
iti
al
Tr
us
t

Tr
ust
O
ve
rT
im
e
Time till next reload/refresh

La
ck
of
Tr
u st