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 1
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, signature card 2
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 more intuitive handling of names 3
X.509 Systems PKCS X.509 RFC S/MIME P1363 proprietary RSA FIPS ANSI Cryptographic Message Syntax encrypted and signed messages PKCS#7 S/MIME draft RFC 2630 Standard EU 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, RFC,... 4
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 new concepts and their support by new protocols 5
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 PKI header PKI body Protection Extra certificates version sender recipient despatch time protection alg transaction no. sender nonce recipient nonce 6
Certificate request 2/2 signing CertReq ID data to be signed algorithm ID signature certificate request proof of possesion Register info certificate template Controls Signed message content type content version client identification alg. characteristics attributes signature algorithm signature version alg. characteristics nested content set of certificates set of CRL info of signatories 7
PKI high level view CA root CA 11 CA 12 CA 21 CA 22 CA 23 CA 31 Certification tree diagram Certification authority certificate repositories Diagram PKI of CA 11 Repository LDAP CA 11 Repository WWW : RA 1 RA 2... RA n Repository k certificate owners PKI clients 8
Uptime Signatures CA hierarchy - example...... E-mail users Uptime root cert Uptime Certificates servers Barclays... customers Visa Int l Visa UK county council... Peter, Juraj NatWest... customers vet inspection... surgeons Cross certification CA 11 CA 12 CA 21 CA 22 CA 23 CA 31 cross certification 9
Certificate types hierarchical root CA certificate certificates for signing Web Server certificates user certificates root cert. CA signing certificates certificate chains server certificates client certificates certificate obtained from a server 10
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 11
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 the technology breaches some general security properties/requirements 12
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 legal disputes 13
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 just SW implementation implies lower security of authentication scheme Different case n:n or n:m authentication there is no single centre quite complicated key management if symmetric algorithms used see VISA system PKI may solve the problem if there is a centre with limited availability transactions take their time 14
what about private key when it is lost? when it is compromised? when one changes employer? when it is deposited/stored by a third party? when it is claimed by a court? when one is out-of-office? when where to go: technology using blacklist (CRL) is (should be) obsolete certification chains, cross certification will never fully meet expectations we do need certificates but information about actual status of the key! Internet browser security is more than doubtful 15
where to go: legislation electronic signature laws are hasty it is not always (in most cases) needed and a bad law causes more problems than solves => next lecture 16