Number of relevant issues

(1)

Kryptografie a informační zabezpečenost, © Daniel Cvrček, 2005

Electronic signature

Lecture 8

Number of relevant issues

• cryptography itself – algorithms for signing documents • key management – generating keys, distribution, key

revocation

• security policy – certificates may contain special attributes that are not standardised

• administrative security – how to access CA private keys • physical security – central computer must be in a very

secure place

• archiving – documents, certificates, revocation lists, … • legal status of the signatures

(2)

Electronic v Digital Signature

• the distinction comes from existing

European law

– electronic signature – any information

identifying sender of a message, e.g. signatures

(text strings) as we know them from emails

– digital signature – signature based on

cryptography, satisfying several security

properties, e.g. unforgebility

Analogy to Hand-written

Signatures

Notion hand-written signature digital signature

message paper with writing electronic data

signature “scribble”written message based on public key

by hand cryptography + msg itself

device for brain capability, private key signing practice, hand skills

device for knowledge, experience, public key certificate

verifying vision/eye,

(3)

Public Key Infrastructures

• complex technologies covering key management

problems related to digital signatures

• first OTS products appeared in nineties

– high price – no applications

– very hard to sell in first years

• currently dozens of PKI solutions – Entrust,

Verisign, RSA, IBM,

• Czech Republic – 1.CA – run by PVT, most of the

banks is running own PKI

Several Standards

• X.509 – hierarchical structure

– hard to penetrate, if it happened, it would be

massive

• PGP – each user creates a domain of trust

– easier to get inside the system

• SPKI/SDSI – names are unique only in a

certain context

(4)

X.509 Systems

PKCS X.509 RFC S/MIME P1363 FIPS ANSI PKCS#7

Cryptographic Message Syntax

encrypted and signed messages S/MIME

draft RFC₂₆₃₀ Standard_EU proprietary

RSA

Standards according to areas

• PKI - X.509, PKCS#10, #12 (#6, #9)

• electronic mail - CMS, S/MIME drafts

• algorithm - PKCS#1, P1363, FIPS, ANSI

• communication protocols - X.509, SSL,

(5)

Design evolution

• idealistic assumptions – there is a central CA, trusted by everyone

– PEM, X.509

– one CA => one policy, certificates do not contain any policies

• realisation - central CA will never be

– PKCS #6, X.509v2, 3

• creation of a homogenous system - PKI is quite a bite

– new standards around X.509

• establishment of national PKI schemes

Current state

• fragmentation => incompleteness, redundancy

– X.509, PKCS #10

– missing requests for revocation, certificate request is only for RSA, there are not assumed different purposes for keys (e.g. signing, encryption)

• Unified model

– based on certificate request (CRMF) allowing all current security properties

– definition of a complete set of messages for PKI management

(6)

What are the problems

• implementations of even basic standards are

incomplete

• MS monopoly => common user cannot

professionally (securely) use certificates

– absurd customer requirements for MS compatibility (money talks)

• Example – certificate import

– simple!??

– pointless number of formats (names?) - DER, BER, 509, p7c, ... binary and with based64, eventually with various other data

Certificate request 1/2

PKI message _version

sender recipient despatch time protection alg transaction no. sender nonce recipient nonce PKI header PKI body Protection Extra certificates

(7)

Certificate request 2/2

ID certificate template Controls certificate request proof of possesion Register info data to be signed algorithm ID signature signing CertReq

Signed message

content type content version alg. characteristics nested content set of certificates set of CRL info of signatories version client identification alg. characteristics attributes signature algorithm signature

(8)

PKI – high level view

CA_root CA₁₁ CA₂₁ CA₁₂ CA₂₃ CA₂₂

CA31 Certification tree diagram

Certification authority

CA

₁₁ Diagram PKI of CA₁₁ RA₁ RA₂

...

RA_n RepositoryLDAP Repository_WWW Repository_k

:

PKI clients certificate owners certificate repositories

(9)

CA hierarchy - example

Uptime “Signatures” Uptime “Certificates” Barclays county council ... _... ... E-mail users Peter, Juraj … ... servers Uptime root cert customers Visa UK NatWest ... vet inspection ... Visa Int’l customers _surgeons

Cross certification

CA₁₁ CA21 CA12 CA23 CA22 CA₃₁ _{cross certification}

(10)

Certificate types

• hierarchical

– root CA certificate – certificates for signing – Web Server certificates – user certificates

• certificate chains

root cert. CA “signing” certificates server certificates client certificates

(11)

… is it in our local database???

Certificate validity

• explicit statement

– valid from

– valid to (e.g. 050814132432)

• we can revoke a certificate if needed

– we tell CA “the certificate is not valid any more!”

• original X.509 – list of revoked certificates

-CRL

(12)

Key/certificate verification

• conservative: key/certificate is valid only when a solid proof is introduced

– real-time confirmation from CA – useful for disputes, “fast” transactions – Online Certificate Status Protocol – OCSP

• liberal: key/certificate is valid until revocation is demonstrated

– CRL – list of revoked certificates

Revocation is a problem of utmost importance!!!

X.509 problems

• complexity! • technology

– certificate revocation

• implicit assumption – certificate is valid • how to detect disclosure of private keys • time delay after certificate revocation • time delay for distribution of CRLs

• amount of data periodically distributed by CA

– secure devices

• secure HW providing crypto and verification of certificate validity/limits of its usage

• problems related to principles, PKI and X.509 is built on

• administration

– usage and running of a PKI system can be very • general security – privacy

(13)

X.509 problems - registration

• existing conflicts

– one key of CA v dozens keys of registration authorities (RA)

• RA security is not equal to that of CA (costs and management)

• a clerk is responsible for registration process

– registration requirements are higher than those for police identification

• RA security is less important than security of CA

– just a stupid attacker (or a weird one) would targeted the whole PKI structure

Some issues we haven’t touched

• (notary) time-stamps

• archiving signed documents

– short term

– long term

(14)

Case study

• bank clients authentication – typical authentication 1:n (n clients authenticating towards a bank)

• Solution 1

– authentication calculator for each client allows secure authentication of bank transactions

– just symmetric crypto used – simple scheme and relatively easy implementation

• Solution 2

– using certificates – a couple of bank visits (usually 2-3) – symmetric, as well as asymmetric crypto needed