COEN 250 Cryptography, Certificates, PKI, X509 Standard.

COEN 250

Cryptography, Certificates, PKI, X509 Standard

Cryptography

Scrambles a plain-text into crypto-text. Enables to descramble plain text.

Originally used to provides confidentiality of information. Now also used for

authentication (of person, of message, …) integrity validity non-repudiation …

Cryptography and the Federal Agency Federal standards documented in Federal

Information Processing Standards (FIPS) Publications

NIST Recommendations and guidelines documented in NIST Special Publications (SPs)

Cryptographic modules and algorithms that are validated against these specifications.

Cryptography and the Federal Agency FIPS:

Mandatory standard Adopted via a signature by the Secretary of Commerce

NIST Recommendation: Similar to FIPS Not signed by the SoC

Example: Federal agency requires use of encryption to protect its data. Approved algorithm shall be used AES and TDEA are the only algorithms currently approved for data

encryption When AES is used, it shall be used as specified in FIPS 197 When TDEA is used, it shall be used as specified in SP 800-16

Cryptography and the Federal Agency Other Standards:

American National Standards Institute (ANSI) X9 standards committee working in security, crypto

www.x9.org

Institute of Electrical and Electronics Engineers (IEEE)

Internet Engineering Task Force (IETF)

Symmetric Cryptography

Uses the same key for encryption, decryption

Symmetric Cryptography

Current StandardsData Encryption Standard (DES) 1977

Broken Withdrawn in 2005

Triple Data Encryption Algorithm (TDEA) Uses DES as a component Not broken, but phased out in 2030

Advanced Encryption Standard (AES)

Asymmetric Cryptography

Uses different key for encryption, decryption

Message Authentication Codes

Condenses message into a short hash

• SHA1, … MD5, … are appropriate cryptographically secure hash functions• For example, encrypt only the MAC with a key known to sender and receiver.

FIPS 198: The Keyed Hash Message Authentication Code

Message Authentication Code

Alternatively, use a secret key. This also provides authentication.

Use of Asymmetric Cryptography

Generic idea: Make one key public.How?

Website Website can be spoofed.

On your business card Works for individuals, requires recipient to type in several

lines of gibberish correctly.

From a trusted source Going back and back: Where does the trust stem from?


Notations: E – public key, D – secret key

EC (M) – encryption of M using key C.

DC(M) – decryption of M using key C.

Asymmetric cryptography key identitiesDEED(M) = M

DDEE(M) = M


Secret Transmission of messagesAlice uses public key of Bob to encrypt her

messages to him: EE(Bob)(M).

Bob uses his private key to decrypt the

message: DD(Bob)EE(Bob)(M).


Signing a message I: Alice encrypts the message with her private key:

ED(Alice)(M).

Bob decrypts with her public key and obtains M =

DE(Alice) ED(Alice)(M).

If M makes sense, Bob knows that someone with

Alice secret key send the message.


Signing a message II This method avoids encryption of the whole message.

Asymmetric cryptography is very compute intensive. Alice uses a MAC of her message: MAC(M). She sends Bob M and ED(Alice)(MAC(M)). Bob calculates

MAC(M) = DE(Alice) (ED(Alice)(MAC(M))). Bob verifies that this is the correct MAC. Bob concludes that the message was sent by

someone knowing Alice’s private key.

Key Management

Generic Rules:Use symmetric cryptography as much as

possible for performance.Never use keys more than once or for more

than one function.Use key wrapping (encrypting keys)

Key Management becomes an issue.

Key Management

Key Management Life Cycles:Key establishment

Key generation Key distribution

Key backup / recovery, key escrowKey replacement / update (rekeying)Key revocationKey expiration / Key termination / Key

destruction

Key Management

Keys have limited lifetimes:Cryptanalysis is easier with more material.

Breaking WEP involves harvesting a large number of packets.

Once found, a compromised key continues to do damage.

Key Management

Key Generation Currently no federal standard for symmetric key generation

Not all pseudo random number generation algorithms and implementations are created equal

Key Transport Distribution of keying material from one party to another party

Key Agreement Protocols that create shared keying material NIST SP 800-56

Key Management Guidelines NIST SP 800-57

Key Management

Key generationUses random number generation

Pseudo-random generation derived from a seed WEP: seed based on user key word. Not as

random as appeared.

Hardware random number generationCombined methods

Key Management

Key distribution Has issues of authentication and confidentiality. Diffie-Hellman protocol solves confidentiality:

Allows two parties to agree on a common secret.

Subject to the man-in-the-middle attack Alice thinks that she shares a secret with Bob. In reality, she communicates with M, and shares the secret with

him. M shares another secret with Bob.

Key Management

Key backup / recovery Accidental loss of key

hardware failure, forgotten password … Control of encrypted information

Employer cannot entrust enterprise-critical data to complete control of a single / group of employees.

Key escrow To preserve possibility of access by law enforcement agencies.

In the UK, it is a crime to withhold a key to encrypted data under subpoena.

In the US, such a law is seen to contradict 5th amendment protection.

Key Management

Key destructionSecure key destruction is far easier than

secure file erasure.Key destruction destroys accessibility to

encrypted data. Key archiving

Necessary for validation of old signatures, of integrity of old messages, …

Key Management

Symmetric key transport:Send symmetric key along, protected by

public key of recipient.Saves on processing time

Diffie-Hellman

Uses calculation modulo p, p a large prime. Chooses generator g.

Ideally, gx, x = 0, …, p -2 runs through all numbers 1, … p -1.

Uses the fact that calculating powers gx is computationally feasible.

But discrete logarithm (given gx find x) is not.

Diffie Hellman

Alice generates random number a mod p. Bob generates random number b mod p. Alice sends Bob ga mod p. Bob sends Alice gb mod p. Alice calculates (gb)a mod p. Bob calculates (ga)b mod p. These numbers are identical and the shared

key.

Diffie Hellman

Man in the middle attack

Bob AliceMan in the Middle

Diffie Hellman

Alice sends Bob ga mod p. But message goes to alien. Alien sends Bob gc

mod p. Bob sends Alice gb mod p.

But message goes to alien. Alien sends Alice gd mod p.

Alice calculates (gd)a mod p. Bob calculates (gc)b mod p. These set up a secure communication

channel between the alien and Bob and one between the alien and Alice.

Diffie Hellman

Secure against eavesdroppers. Can be secured against man-in-the-middle

by using authenticated gb mod p or by using a published value gb mod p.

Diffie Hellman and all other schemes The problem is one of authentication and

trust.

Certificates

THE authentication mechanism for E-commerce. Allows customers to authenticate the e-merchant. Misrepresentation of e-merchants is the goal of

phishing.

Certificates

Working Mechanism Certificate is a signed message containing an (e-

merchants) public key. Signer needs to be trusted.

Signer public key needs to be loaded at user workstation. User needs to be able to trust that key.

Certificates

Browse to website

Certification Authority

OS Vendor installs CA public key in Browser

ECA

Sends ECA(Ms. Li, ELi), ELi(Session Key)

Authenticates by using session key.

Certificates

Key distributionCrucial for authentication, privacy, signing, …Public Key Technology can use Certificates

Certificate Authority (CA) generates certificates: Certificate = (Name, Public Key)signed by CA

All nodes need to be preconfigured with public key by CA.

Certificate Authority vs.

Key Distribution Center

CA in contrast to KDC: CA does not need to be online. CA not a distributed computing entity.

Simpler, hence more secure. CA crash merely prevents setting up new users. Certificates are not security sensitive. They can be stored

anywhere with universal read privileges. Deleting a certificate would disable the use of the public key.

A compromised CA cannot read conversations, fake conversations, …

However, it can issue bogus certificates.

CA more secure, more convenient than KDC.

Certificate Revocation

A certificate guarantees a public key.But public keys become unusable if the

corresponding private key is stolen. Certificates should not be eternal

They need an expiration date.CA needs to be able to revoke a public key.

Certificate Structure

Certificate includes:User’s nameUser’s public keyExpiration timeSerial number of certificateCA name Issuing CA’s signature on the entire contents of

the certificate.


Certificate Revocation List (CRL)Published periodically by each CA.Lists serial numbers of certificates that should

not be honored.CRLs have issue time.


Push or Pull model Pull: Users access CRL remotely. Push: Broadcast CRL.

Needs reliable distribution mechanism. Needs small CRL.

US DoD Multi-level Information System Security Initiative (MISSI) developed a PKI for the Defense Messaging System.

Used CRL broadcasting only for revocation caused by key compromises.

Reliable access to all participants.


Make certificate revocation unnecessary by handing out only short-lived certificates.

Certificate Revocation Lists

CRLsCRLs can be very large.Publish mostly only a -list.

-list can be very short, often empty. Users update their private copy of the CRL.

From time to time, publish a full list, or give one only to new users.


First Valid CertificateGoal: Allow to compress CRLs.Certificates have no expiration date.CRL contains a first valid certificate field.All certificates with a serial number lower than

the valid certificate field are invalid.


On-Line Revocation Service (OLRS)System can be queried over the net whether a

certificate is invalid. If unavailable, Alice can choose to accept

certificates on trust. OLRS certificates

OLRS can issue a certificate stating: “Bob’s certificate is valid as of 6:05 GMT, January

20, 2005.”


Good Lists vs. Bad Lists Good lists are much bigger. Good list publishes all licenses.

Hence, good list contains hashes of certificates.

Good lists solve one security problem: A CA employee can issue a bogus certificate off the books,

possibly reusing a valid serial number. The bogus certificate cannot be put on the bad list, but the

good list can be audited.

Certification Paths

Alice wants to communicate with Bob: Bob has a certificate from Cristal. Alice does not know Cristal. Therefore, Alice needs a certificate of Crystal’s public

key. Crystal has a certificate from Dan. Alice does not know Dan. Therefore Alice needs a certificate of Dan’s public

key. …

Trust Anchors

Alice needs to trust someone in the certificate chain.

Alice Bob Crystal Dan

EveFredMicrosoft

Certificate Authorities

Organization might have its own Certificate Authority.

Independent Certificate Authorities are like notaries:Trusted.Disinterested.Attesting to designated facts.

Public Key Infrastructure

PKI consists of the components necessary to securely distribute public keys.Certification AuthoritiesRepository for retrieving certificatesMethod of revoking certificatesMethod of evaluation a chain of certificates

Public Key Infrastructure

Issuer: signs certificate with name and key. Subject: name contained in a certificate. Target: The name in the name-key association

that someone wants to trust. Verifier / Relying Party: Evaluator of a chain of

certificates. Principal: Anyone with a public key. Trust Anchor: public key that someone has

decided to always trust.

PKI Trust Models

Monopoly:There is one single CA in the world.

Vatican, US government, UN, Microsoft, Sun, Verisign, Chief rabbinate, …

The key of the universal trust anchor could never be changed without causing mayhem.

CA needs to verify every-one.

PKI Trust Model

Monopoly + Registration Authorities (RA)Monopolistic CA chooses RAs all over the

world.RA authenticate and issue certificates

accordingly.RA receive a certificate signed by the CA.

In principle, a CA could check on what a RA does, but in general, they just rubber-stamp.

PKI Trust Model

Monopoly + Delegated CA Monopolistic CA issues certificates to

other CAs.Vouching for keys and vouching for

trustworthiness. CAs issue their own certificates.

PKI Trust Model

OligarchyAllow for some /

many root CAsUsed in web

browsers.Any wrongdoing

at any of these CAs can cause serious trouble.

PKI Trust Model

Verisign once certified Microsoft fraudulently.

PKI Trust Model

AnarchyUsed by PGPUsers configure trust anchors, use rules on

when to trust, …Everyone can issue certificates.

PKI Trust Model

Name constraintsUse internet name space.CA only trusted within a certain domain.SCU CA to be trusted with certifying SCU

students, but not to be trusted with [email protected].

PKI Trust Model

Top-Down with name constraintsMonopolistic: there is one root key.CAs responsible for their namespace.

root

.com .gov .edu .fr .uk .de

.ucsc.edu .scu.edu

.coen

PKI Trust Model

Bottom up with name constraints SCU can set up their own CA. So can UCSC. Eventually, they want to cross-link. Business opportunity to provide cross-link

certification service, but business subject to competition.

Federal Bridge Certification Authority FBCA supports interoperability among Federal

Agency PKI domains P2P model

X.509 Certificate Policy for the FBCA Four different assurance levels

Rudimentary Basic Medium High Test

Certificate Policies

Certificates can spell policies that limit the use of the certificate.

Certification Storage

With Issuer With Subject In a certificate repository.

Choice depends on the PKI model.

Certificate Generation

Creation of public / private key. Subject authentication

Certificate Distribution

Certificate can Accompany signatureDistributed via web services

X.509 Certificate Format

X.509 Version Number

Serial Number

Signature Algorithm Identifier

Issuer (X.500 Name)

Validity Period (Start – Expiration dates / times)

Subject (X.500 Name)

Subject Public Key Information: Algorithm Identifier, Public Key Value

Issuer Unique Identifier

Subject Unique IdentifierCA Digital Signature

X.500 Names

X.500 Name in Adobe Acrobat Digital Signature

X.500 Names

Root

USA

CA = US

Santa Clara University

O = Santa Clara University

Department of Computer Engineering

OU = Department of Computer Engineering

Thomas Schwarz, S.J.

CN = Thomas Schwarz, S.J.

Attributes:Telephon = 551-6064email = tjschwarz @scu.edutitle = Associate Professor

DN = {C=US, O=Santa Clara University, OU = Department of Computer Engineering, CN = Thomas Schwarz, S.J.}

X.500 Names

X.500 directory consists of a set of entries. Each entry is associated with one real-world

object. Person Device Organization

Each object has a distinguished name (DN). Entry also has a set of attributes.

X.500 Names

Entries logically organized in a directory tree. Directory Information Tree (DIT)

Entries have attributes. Each link in the directory tree is labeled by an attribute

type and a relative distinguished name (RDN). C ~ Country O ~ Organization OU ~ Organizational Unit CN ~ Common Name

Distinguished names are formed by concatenating the labels on the way from root to the object.

X.500 Names

Root

USA

CA = US

Santa Clara University

O = Santa Clara University

Department of Computer Engineering

OU = Department of Computer Engineering

Thomas Schwarz, S.J.

CN = Thomas Schwarz, S.J.

Attributes:Telephon = 551-6064email = tjschwarz @scu.edutitle = Associate Professor

DN = {C=US, O=Santa Clara University, OU = Department of Computer Engineering, CN = Thomas Schwarz, S.J.}

X.500 Names

X.500 names are unique, but can be reused. I leave SCU, and ten years later they hire another

Thomas Schwarz, S.J. Unlikely in my case, more likely for John Smith.

This can be resolved by using two attributes as labels: CN = Thomas Schwarz, S.J. EN = 000023812

This is the reason why X.509 uses unique identifiers. Even though they are difficult to administer.


X.509 Version Number

Serial Number


Issuer (X.500 Name)





Subject Unique IdentifierCA Digital Signature


X.509 uses identifiers for the methods used to form Issuer signature, Certified public key.

These methods are objects that need to be registered.

Objects have unique names, based on the Abstract Syntax Notation 1 Standard.

ASN.1

Based on hierarchical structure. Top level uses integer values:

0 ITU-use 1 ISO use 2 joint ITU-ISO use.

Second level depends on first level for different standards administered by the unit. Under 2, 16 specifies country. Under 2, 16, 840 specifies US.

ASN.1

Based on hierarchical structure. Top level uses integer values:

0 ITU-use 1 ISO use 2 joint ITU-ISO use.

Second level depends on first level for different standards administered by the unit. Under 2, 16 specifies country. Under 2, 16, 840 specifies US.

ASN.1

0 1 2

16 (country)

840 (USA)

1 (Organization)

1589932 SCU

35 COEN

1 Algorithms

1 SuperSchwarz1

Object-Identifier:

{joint-iso-itu-t (2) country (16) us (840) organization (1) SCU (1589932) COEN (35) Algorithms (1) SuperSchwarz1 (1) }

ASN.1

It can happen that the same object gets different names.The lower ranks of the tree are not

administered centrally.


Naming is a problem.S/MIME uses X.509 certificates.Needs to associate certificates with email

addresses. Insists that the name contains a component

[email protected]. Only reads this component.

Later versions require to put email address under SUBJECTALTNAME.


Naming is a problem.SSL has a similar problem.URLs use the DNS system, not X.500

Some browsers give up, just check whether the certificate is validly signed!

Others insist that CN portion contains the DNS name.


Naming is a problem.X.509 directory service largely non-existent.DNS exists.


X.509 Version 3:Single subject needs various public keys and

hence various certificates.Application-specific namingCertificates have different levels of security,

hence different levels of trust.


X.509 Version 3:Adds an extension field.

Extension field can contain various entries.

X.509 v.3 Certificate Format

X.509 Version Number = 3

Serial Number


Issuer (X.500 Name)





Subject Unique Identifier

ExtensionsCA Digital Signature

Extension Type Criticality Extension Field ValueExtension Type Criticality Extension Field ValueExtension Type Criticality Extension Field ValueExtension Type Criticality Extension Field Value


Naming no longer restricted to X.500 naming system.


New set of standard extensions.Key information.Policy information.Subject and issuer attributes.Certification path constraints.Extensions related to CRLs.

PKIX

Working group established by IETF in 1994. PKIX recommended extensions:

AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage PrivateKeyUsagePeriod CertificatePolicies PolicyMappings SubjectAltName

PKIX

PKIX recommended extensions: IssuerAltName SubjectDirectoryAttribute BasicConstraints NameConstraints PolicyConstraints ExtendedKeyUsage CRLDistributionPoints InhibitAnyPolicy FreshestCRL AuthorityInfoAccess SubjectInfoAccess

PKIX CRL

CRL entry contains Signature Issuer ThisUpdate (time CRL was issued.) NextUpdate UserCertificate

RevocationDate CRLEntryExtensions CRLExtensions

AlgorithmIdentifier Encrypted

Repeats for each entry.

PKIX Online Certification Status Protocol Implements online status checking for

certificates.Real-time status checks.But data is valid for a validity window.

Other Standards

PBP standard WAP WTLS

Replaces ASN.1 names with simpler ones. DNSSEC

A type of a certificate for DNS environment only.

SPKI (Simple PKI) RFC 2693,

COEN 250 Cryptography, Certificates, PKI, X509 Standard.

Documents

key public

public key of bob

private key

use of encryption

alice secret key

e public key

message iithis method

bob decrypts