Real-World Problems of PKI Hierarchies Daniel Cvrček Department of Computer Science and Engineering, Brno University of Technology SPI Conference 2001, Daniel Cvrček, 1/18

Media Image of Digital Signature Implicitly assumes X.509 standard Allows easy use of public key technology Secures , web access, authenticates documents Part of office packages - nothing else needed to buy Security of digital signature is 99, % Ready to use professionally (court proof) Ready to use technology with no risks SPI Conference 2001, Daniel Cvrček, 2/18

However, it is not true! SPI Conference 2001, Daniel Cvrček, 3/18

Facts and Problems The technology is very complex Commercial products are very complex - security cannot be efficiently evaluated Vendors are not able to implement the technology entirely –why to discern certificates for , web access, object-signing,... when it is all the time one certificate just slightly changing –when issued two certificates for alleged MS employees there were introduced more than twenty patches for MS software to cover that Pure software solutions do not ensure security of users’ public keys SPI Conference 2001, Daniel Cvrček, 4/18

General Classes of Problems Secure signature creation (signing) device Secure signature verification device Signer’s document viewer Signature attributes viewer Signer interaction component Signer’s authentication component Data hashing component Signer’s document composer Certificate content viewer Signed data object composer All parts have to satisfy some general level of security Following slides cover not the implementation problems but problems resulting from the very technology - X.509 SPI Conference 2001, Daniel Cvrček, 5/18

Problems of The X.509 Technology Technology the problems related to the principles on which the X.509 PKI ideas are based Administration the problems resulting from application and usage of the technology General security application of the technology seems to violate some general security requirements SPI Conference 2001, Daniel Cvrček, 6/18

Technology Problems Revocation of certificates –implicit assumption - certificate is valid –detection of secret key disclosure –time delay for certificate revocation –time delay for distribution of revoked certificates –amount of data distributed periodically by CA Secure devices –secure HW able to perform cryptographic operations and verify certificate validity and conditions for its usage SPI Conference 2001, Daniel Cvrček, 7/18

Detection of Secret Key Disclosure Very hard to detect at all Time between disclosure and detection may be in hours or days, time needed for abuse may be counted in milliseconds according to law - owner is responsible for private key usage until requesting CA to revoke appropriate certificate There is no trusted way to identify place or time of signature creation assuming digital signature as defined by the Czech Law Certificate validity is typically measured in years SPI Conference 2001, Daniel Cvrček, 8/18

Distribution of Revocation Information When implemented then CRL –one needs next CRL to be sure that the key has not been misused in the previous period On-line response protocols have worse security properties (manipulation with secret keys) CRL is not suitable for time-critical applications –time-validity of CRL is typically 24 hours –we suppose that frequently changed symmetric key may be more secure Conditional validity may be a solution –one confirms validity of a secret key when using it SPI Conference 2001, Daniel Cvrček, 9/18

Case Study relying parties verifying 10 signatures per day, 24 hour-validity of CRL, size of CRLs 10 kB. CRL - it implies load peak 35 requests per second and data connection 2.8 Mbps. Over-issued CRLs - load peak decreased, with over-issuing with period 3 hours is the peak 9.25 requests per second and data connection needed is 740 kbps. Problem: which CRL is valid? Segmented CRLs - CRL is split into several smaller ones (e.g. 1 kB); risk of necessity to download several CRLs; with a good, very good luck 280 kbps. Problem: additional processing requirements (which CRL is the correct one). On-line status protocol - the size of the response is under 1 kB but frequency is about 35 per second all the day. Problem: treatment of signature secret keys. SPI Conference 2001, Daniel Cvrček, 10/18

Secure Devices The problem is for a separate lecture –determination of the necessary security level (risk analysis?) –methodology for evaluation of the security –the process of evaluation itself –cost of secure devices Should the law specify requirements for secure usage of digital signature? Definitely yes, but how to do it? SPI Conference 2001, Daniel Cvrček, 11/18

Administration Problems Certification policies - cooperation among CAs –expressing the policy used for the certificate –ensuring fulfillment of some quality requirements –comparison of certificates from different CAs Trustfulness of trusted third parties –again, the basic problem with security evaluation Registration processes –contact between human and digital environment SPI Conference 2001, Daniel Cvrček, 12/18

Certification Policies Non-existence of a common recommendation for policy specification implies vendor solutions –how to explain policies in certificates –how to compare policies from different CAs –how to compare certificates’ quality Federal Bridge Certification Authority Initiative - already running from mid-1998 bottom-up model general model for the CAs cooperation through a bridge CA pilot projects SPI Conference 2001, Daniel Cvrček, 13/18

Registration Processes There are conflicts –one CA’s signature key vs. tens or hundreds RAs’ keys security of RAs is not the same as for CA (economic reasons) –responsibility of registration process lays fully on the registration clerk requirements for registration are higher then for police identification –security of RA is less important than security of CA however, just stupid attacker (or a very special one, e.g. competitor) would want to destroy the whole PKI structure SPI Conference 2001, Daniel Cvrček, 14/18

General Security Secret key generation holder's control / certifiably secure manner Secret key storage and backup secure / uninterrupted possession of the holder Secret key escrow - why at all? Secret key access exempt from court orders and search warrants Certification identification requirements overwhelming requirements Registers of certificates obligatory / multipurpose identification database SPI Conference 2001, Daniel Cvrček, 15/18

Alternatives Symmetric key encryption PGP - PKI with very strong users’ responsibility for the security of the scheme SPKI/SDSI –different treatment of names - subject identification –different principles for certificate revocations (positive CRL - revalidation) Private credentials allow signature verification without revealing signer identity prevent linking separate actions SPI Conference 2001, Daniel Cvrček, 16/18

Authentication of bank clients - typical identification 1:n (n clients and 1 bank) Solution 1 authentication calculator for each client allows secure authentication during bank transactions just symmetric key cryptography used - simple scheme and implementation Solution 2 public key certificates used - several visits of the bank (2 at least) symmetric and asymmetric cryptography just software solution implies lower security of the scheme Case Study SPI Conference 2001, Daniel Cvrček, 17/18

Real security is hard work. There is no cure-all, especially not PKI Ellison, Schneier SPI Conference 2001, Daniel Cvrček, 18/18