Public Key Infrastructure

tell me in plain English AND THEN

deep technical how PKI works
Steve Lamb
stephlam@microsoft.com
http://blogs.technet.com/steve_lamb
IT Pro Security Evangelist
Microsoft Ltd

Objectives
Demystify commonly used terminology
Explain how PKI works
Get you playing with PKI in the lab
Make some simple recommendations

Agenda
Foundational Concept (level 200)
PKI and Signatures (level 330)
Recommendations (level 310)
Reference material
Common Algorithms (level 360)

What can PKI enable?

Secure Email sign and/or encrypt messages
Secure browsing SSL authentication and encryption
Secure code authenticode
Secure wireless PEAP & EAP-TLS
Secure documents Rights Management
Secure networks segmentation via IPsec
Secure files Encrypted File System(EFS)

Foundational Concepts

Encryption vs. Authentication

Encrypted information cannot be automatically
trusted
You still need authentication
Which we can implement using encryption, of
course

Assets
What we are securing?
Data
Services (i.e. business etc. applications or their
individually accessible parts)

This session is not about securing:

People (sorry), cables, carpets, typewriters and
computers (!?)

Some assets are key assets

Passwords, private keys etc

Digital Security as Extension of

Physical Security of Key Assets
Strong Physical
Security of KA

Weak Physical
Security of KA

Strong Physical
Security of KA

Strong Digital
Security

Strong Digital
Security

Weak Digital
Security

Good Security
Everywhere

Insecure
Environment

Insecure
Environment

Symmetric Key Cryptography

Plain-text input
The quick
brown fox
jumps over
the lazy
dog

Cipher-text

Plain-text output

AxCv;5bmEseTfid3)f
GsmWe#4^,sdgfMwir
3:dkJeTsY8R\s@!
q3%

The quick
brown fox
jumps over
the lazy
dog

Encryption

Decryption

Same key
(shared secret)

Symmetric Pros and Cons

Strength:
Simple and really very fast (order of 1000 to 10000
faster than asymmetric mechanisms)
Super-fast (and somewhat more secure) if done in
hardware (DES, Rijndael)

Weakness:
Must agree the key beforehand
Securely pass the key to the other party

Public Key Cryptography

Knowledge of the encryption key doesnt give
you knowledge of the decryption key
Receiver of information generates a pair of keys
Publish the public key in a directory

Then anyone can send him messages that only

she can read

Public Key Encryption

Clear-text Input
The quick
brown fox
jumps over
the lazy
dog

Cipher-text

Clear-text Output

Py75c%bn&*)9|
fDe^bDFaq#xzjFr@g
5=&nmdFg$5knvMdr
kvegMs

The quick
brown fox
jumps over
the lazy
dog

Encryption

public

Recipients
public key

Decryption

Different keys

privat
e

Recipients
private key

Public Key Pros and Cons

Weakness:
Extremely slow
Susceptible to known ciphertext attack
Problem of trusting public key (see later on PKI)

Strength
Solves problem of passing the key
Allows establishment of trust context between
parties

Hybrid Encryption (Real World)

Launch key
for nuclear
missile
RedHeat
is...

Symmetric
encryption
(e.g. DES)

Users
public key
(in certificate)

RandomlyGenerated
symmetric
session key

RNG

*#$fjda^j
u539!3t
t389E *&\@
5e%32\^kd

Symmetric key
encrypted asymmetrically
(e.g., RSA)

Digital
Envelope

As above, repeated
for other recipients
or recovery agents

Digital
Envelope

Other recipients or
agents public key
(in certificate)
in recovery policy

Hybrid Decryption
*#$fjda^j
u539!3t
t389E *&\@
5e%32\^kd

Launch key
for nuclear
missile
RedHeat
is...

Symmetric
decryption
(e.g. DES)
Symmetric
session key

Recipients
private key

Asymmetric
decryption of
session key (e.g. RSA)

Digital envelope
contains session
key encrypted
using recipients
public key

Digital
Envelope

Session key must be

decrypted using the
recipients private
key

Breaking It on $10 Million

Symme-tric ECC Key
Key

RSA Key

Time to
Break

Machines

Memory

56

112

420

< 5 mins

10000

Trivial

80

160

760

600
months

4300

4GB

96

192

1020

3 million
years

114

170GB

128

256

1620

10E16
years

0.16

120TB

From a report by Robert Silverman, RSA Laboratories, 2000

PKI and Signatures

Public Key Distribution Problem

We just solved the problem of symmetric key distribution
by using public/private keys
But
Scott creates a keypair (private/public) and quickly tells
the world that the public key he published belongs to Bill
People send confidential stuff to Bill
Bill does not have the private key to read them
Scott reads Bills messages

Eureka!
We need PKI to solve that problem
And a few others

How to Verify a Public Key?

Two approaches:
1. Before you use Bills public key, call him or meet
him and check that you have the right one
Fingerprint or hash of the key can be checked on the
phone

2. Get someone you already trust to certify that the

key really belongs to Bill
By checking for a trusted digital signature on the key
But there has to be one
And you have to have friends to trust in first place

Trust Models
Web-of-Trust (PGP)
Peer-to-peer model
Individuals digitally sign each other keys
You would implicitly trust keys signed by some of your friends

Trusted Authority + Path of Trust (CAs)

Everyone trusts the root Certificate Authority (Verisign,
Thawte, BT etc.)
CA digitally signs keys of anyone having checked their
credentials by traditional methods
CA may even nominate others to be CAs and you would
trust them automatically, too

Trust Models Issues and Future

Web-of-trust is more, erh, trustworthy
But it is time-consuming, requires lots of work and general
public doesnt understand it

CAs tend to be a little bit like a big brother as we all have

to trust them implicitly
But it is a simpler model, easier to deploy and manage

Combination strategy?
Lets trust a CA that verifies keys by traditional strong methods
and peer-to-peer recommendations

Creating a Digital Signature

Message or File

128 bits
Message Digest

This is a
really long
message
about
Bills

Digital Signature
Jrf843kjfgf*

$&Hdif*7oU
sd*&@:<CH
DFHSD(**

Py75c%bn&*)9|
fDe^bDFaq#xzjFr@g
5=&nmdFg$5knvMdr
kvegMs
Hash
Function
(SHA, MD5)

Calculate a short
message digest from
even a long input
using a one-way
message digest
function (hash)

Asymmetric
Encryption

privat
e

Signatorys
private key

Verifying a Digital Signature

Digital Signature
Jrf843kjf
gf*$&Hd
if*7oUsd
*&@:<CHD
FHSD(**

Asymmetric
decryption
(e.g. RSA)

Py75c%bn&*)
9|fDe^bDFaq
#xzjFr@g5=
&nmdFg$5kn
vMdrkvegMs

? == ?

Signatorys
public key

Everyone has
access to trusted
public key of the
signatory

Are They Same?

Same hash function
(e.g. MD5, SHA)

This is a
really long
message
about Bills

Py75c%bn&*)
9|fDe^bDFaq
#xzjFr@g5=
&nmdFg$5kn
vMdrkvegMs

Original Message

Hash (Digest) Functions

MD5 and SHA
Just a hash value of between 128 bits (MD5) and
512 bits of key (SHA512)

Great support in .NET and in CryptoAPI of

Windows
.NET Fx also supports shorter SHAs (160, 256, and
384 bits)

Please dont use (ever) any function with 64bit

(or smaller) result

Message Authentication Codes

MACs Typically, combination of a hash function and a
symmetric encryption
Integrity, authenticity but not non-repudiation
Must share the key!

HMAC
Digest + shared-secret encryption for up to 160 bit results

MACTripleDES
Encryption using 8, 16 or 24 bytes of TripleDES key on top of
a hash
64 bit result (ouch!)

All of the above implemented in .NET Fx

Many others exist, notably UMAC

Certificates
The simplest certificate just contains:
Information about the entity that is being certified to
own a public key
That public key

And all of this is

Digitally signed by someone trusted (like your friend
or a CA)

X.509 Certificate
Certificate Authority Digital Signature
of All Components Together:
Serial Number
Issuer X.500
Distinguished Name
Validity Period
Subject X.500
Distinguished Name
Subject Public Key
Information
Key/Certificate Usage
Extensions

OU=Contoso
The Key or Info About It

Authentication with Certificates

1.

Melinda gets Bills certificate

2.

She verifies its digital signature

She can trust that the public key really belongs to Bill
But is it Bill standing if front of her, or is that Scott?

3.

Melinda challenges Bill to encrypt for her a phrase etc. she just made
up (I really need more shoes)

4.

Bill has, of course, the private key that matches the certificate, so he
responds (*&$^%$&fhsdf*&EHFDhd62^&)

5.

Melinda decrypts this with the public key she has in the certificate
(which she trusts) and if it matches the phrase she challenged Bill
with then it must really be Bill himself!

By the way, thats the basic concept of how SSL works

Whats in the Store?

Most certificates are safe
No need to protect them too much, as they are digitally signed
and only contain publicly available information
Store anywhere, a file or a dumb memory-only smartcard

Private keys (and certs that include them) that match the
public key are extremely vulnerable
It is a Key Asset
You must protect them well
Store in Protected Storage on your OS or a smart
smartcard that will have crypto functionality on board
Axaltos .NET-enabled smart cards for instance

Word About Smartcards

Some smartcards are dumb, i.e. they are only a memory
chip
Not recommended for storing a private key used in a challenge test
(verifying identity)
Anyway, they are still better than leaving keys on a floppy disk or on
the hard drive

Cryptographically-enabled smartcards are more expensive

but they give much more security
Private key is secure and used as needed
Additional protection (password, biometrics) is possible
Hardware implements some algorithms
Self-destruct is possible

Certification Hierarchy
Most organisations do not use just one root key for
signing certificates
Dangerous, if that one key is compromised
Does not scale to large organisations
Difficulty in managing responsibility

Certificate Hierarchies
Start with CA root cert
Create more levels in your organisation (for departments etc.)

Validating a cert possibly involves validating a path of

trust
Cross-certification is also possible
This is the heart of Planning of PKI

Certificate Validation
Essentially, this is just checking the digital signature
But
You may have to walk the path of all subordinate
authorities until you reach the root
Unless you explicitly trust a subordinate CA

In Xanadu We Trust
(installed root CA
certificate)
Check DS of
OCG CA

I: PB CA
S: Rafal

Check DS of
Xanadu

I: Xanadu Root
S: PB CA

I: Xanadu Root
S: Xanadu Root

Recommendations
Dont be scared of PKI!
Set up a test environment to enable hyou to
play
Minimise the scope of your first implementation
Read up on CP & CPS
Document the purpose and operating
procedures of your PKI

Summary
Cryptography is a rich and amazingly mature
field
We all rely on it, everyday, with our lives
Know the basics and make good choices
avoiding common pitfalls
Plan your PKI early
Avoid very new and unknown solutions

References
Visit www.microsoft.com/security
Read sci.crypt (incl. archives)
Attend SEC499 for Encryption in Detail on Friday at 14.45
in Room 1
For more detail, read:
Cryptography: An Introduction, N. Smart, McGraw-Hill, ISBN 0-07-709987-7
Practical Cryptography, N. Ferguson & B. Schneier, Wiley, ISBN 0-471-22357-3
Contemporary Cryptography, R. Oppliger, Artech House, ISBN 1-58053-642-5 (to be
published May 2005, see http://www.esecurity.ch/Books/cryptography.html )
Applied Cryptography, B. Schneier, John Wiley & Sons, ISBN 0-471-11709-9
Handbook of Applied Cryptography, A.J. Menezes, CRC Press, ISBN 0-8493-85237, www.cacr.math.uwaterloo.ca/hac (free PDF)
PKI, A. Nash et al., RSA Press, ISBN 0-07-213123-3
Foundations of Cryptography, O. Goldereich,
www.eccc.uni-trier.de/eccc-local/ECCC-Books/oded_book_readme.html
Cryptography in C and C++, M. Welschenbach, Apress,
ISBN 1-893115-95-X (includes code samples CD)

Demonstrations
Secure Email sign and/or encrypt messages
Secure browsing SSL auth and encryption
Secure code authenticode - sigcheck
Secure wireless PEAP & EAP-TLS
Secure documents Rights Management
Secure networks segmentation via IPsec
Secure files Encrypted File System(EFS)

Thanks to Rafal Lukawiecki for providing some of the content

for this presentation deck his contact details are as
follows
rafal@projectbotticelli.co.uk
Strategic Consultant, Project Botticelli Ltd

Copyright 2004 Project Botticelli Ltd & Microsoft Corp. E&OE. For informational purposes only. No warranties of
any kind are made and you have to verify all information before relying on it. You can re-use this presentation as long
as you read, agree, and follow the guidelines described in the Comments field in File/Properties.

Common Algorithms

DES, IDEA, RC2, RC5, Twofish

Symmetric
DES (Data Encryption Standard) is still the most popular
Keys very short: 56 bits
Brute-force attack took 3.5 hours on a machine costing US$1m in
1993. Today it is done real-time
Triple DES (3DES) more secure, but better options about
Just say no, unless value of data is minimal

IDEA (International Data Encryption Standard)

Deceptively similar to DES, and not from NSA
128 bit keys

RC2 & RC5 (by R. Rivest)

RC2 is older and RC5 newer (1994) - similar to DES and IDEA

Blowfish, Twofish
B. Schneiers replacement for DES, followed by Twofish, one of the
NIST competition finalists

Rijndael (AES)
Standard replacement for DES for US government, and,
probably for all of us as a result
Winner of the AES (Advanced Encryption Standard)
competition run by NIST (National Institute of Standards and
Technology in US) in 1997-2000
Comes from Europe (Belgium) by Joan Daemen and Vincent
Rijmen. X-files stories less likely (unlike DES).

Symmetric block-cipher (128, 192 or 256 bits) with

variable keys (128, 192 or 256 bits, too)
Fast and a lot of good properties, such as good immunity
from timing and power (electric) analysis
Construction, again, deceptively similar to DES (Sboxes, XORs etc.) but really different

CAST and GOST

CAST
Canadians Carlisle Adams & Stafford Tavares
64 bit key and 64 bit of data
Chose your S-boxes
Seems resistant to differential & linear cryptanalysis and only way to
break is brute force (but key is a bit short!)

GOST
Soviet Unions version of DES but with a clearer design and many
more repetitions of the process
256 bit key but really 610 bits of secret, so pretty much tank quality
Backdoor? Who knows

Careful with Streams!

Do NOT use a block cipher in a loop
Use a crypto-correct technique for treating
streams of data, such as CBC (Cipher Block
Chaining)
For developers:
.NET Framework implements it as ICryptoTransform on a
crypto stream with any supported algorithm

RC4
Symmetric
Fast, streaming encryption

R. Rivest in 1994
Originally secret, but published on sci.crypt

Related to one-time pad, theoretically most secure

But!
It relies on a really good random number generator
And that is the problem

Nowadays, we tend to use block ciphers in modes of

operation that work for streams

RSA, DSA, ElGamal, ECC

Asymmetric
Very slow and computationally expensive need a computer
Very secure

Rivest, Shamir, Adleman 1978

Popular and well researched
Strength in todays inefficiency to factorise into prime numbers
Some worries about key generation process in some implementations

DSA (Digital Signature Algorithm) NSA/NIST thing

Only for digital signing, not for encryption
Variant of Schnorr and ElGamal sig algorithm

ElGamal
Relies on complexity of discrete logarithms

ECC (Elliptic Curve Cryptography)

Really hard maths and topology
Improves RSA (and others)

Quantum Cryptography
Method for generating and passing a secret key or a random stream
Not for passing the actual data, but thats irrelevant

Polarisation of light (photons) can be detected only in a way that

destroys the direction (basis)
So if someone other than you observes it, you receive nothing useful
and you know you were bugged

Perfectly doable over up-to-120km dedicated long fibre-optic link

Seems pretty perfect, if a bit tedious and slow
Practical implementations still use AES/DES etc. for actual encryption
Magiq QPN: http://www.magiqtech.com/press/qpn.pdf

Dont confuse it with quantum computing, which wont be with us for

at least another 50 years or so, or maybe longer

MD5, SHA
Hash functions not encryption at all!
Goals:
Not reversible: cant obtain the message from its hash
Hash much shorter than original
Two messages wont have the same hash

MD5 (R. Rivest)

512 bits hashed into 128
Mathematical model still unknown
But it resisted major attacks

SHA (Secure Hash Algorithm)

US standard based on MD5

Diffie-Hellman, SSL, Certs

Methods for key generation and exchange
DH is very clever since you always generate a new keypair for each asymmetric session
STS, MTI, and certs make it even safer

Certs (certificates) are the most common way to

exchange public keys
Foundation of Public Key Infrastructure (PKI)

SSL uses a protocol to exchange keys safely

See later

Cryptanalysis
Brute force
Good for guessing passwords, and some 40-bit symmetric keys (in
some cases needed only 27 attempts)

Frequency analysis
For very simple methods only (US mobiles)

Linear cryptanalysis
For stronger DES-like, needs 243 plain-cipher pairs

Differential cryptanalysis
Weaker DES-like, needs from 214 pairs

Power and timing analysis

Fluctuations in response times or power usage by CPU

Strong Systems
It is always a mixture! Changes all the time
Symmetric:
AES, min. 128 bits for RC2 & RC5, 3DES, IDEA, carefully
analysed RC4, 256 bit better

Asymmetric:
RSA, ElGamal, Diffie-Hellman (for keys) with minimum 1024
bits (go for the maximum, typically 4096, if you can afford it)

Hash:
Either MD5 or SHA but with at least 128 bit results, 256 better

Weak Systems
Anything with 40-bits (including 128 and 56 bit versions
with the remainder fixed)
Most consider DES as fairly weak algorithm

CLIPPER
A5 (GSM mobile phones outside US)
Vigenre (US mobile phones)
Dates from 1585!

Unverified certs with no trust

Weak certs (as in many class 1 personal certs)