Asymmetric cryptosystems fundamental problem: authentication of public keys

Transcription

1 Network security Part 2: protocols and systems (a) Authentication of public keys Università degli Studi di Brescia Dipartimento di Ingegneria dell Informazione 2014/2015

2 Asymmetric cryptosystems fundamental problem: authentication of public keys A must know K pubb Usually B must know K puba Exchanging public keys seldom happens on secure channels, i.e., channels that guarantee integrity and authenticity (of the source) Network scalability: in an n-node network, each node would need to memorize, and manage (update, remove, ), (n-1) public keys How to manage public key revocation? Scenario: A realizes somebody stole her K priva A must let all (n-1) network nodes that her keypair is not valid anymore 2

3 Some scenarios Alice sends her public key to Bob to run Diffie-Hellman and derive an ephemeral key run RSA and sign some data How can Bob be sure that the key he received is actually from Alice? What happens if Trudy poses as Alice? Bob receives a fake Alice s K puba from Trudy Ok, they can run DH and Bob keeps thinking she is Alice K puba Alice Trudy Bob Bob Bob K puba 3

4 Some scenarios/2 Note: This does not work, find why. Alice I will make Bob believe I m Alice Trudy Bob K puba Does Trudy have KprivA? This does work instead Alice I will make Bob believe I m Alice: I replace KpubA with my own Trudy Bob Bob K puba K puba One key is like the other for Bob: no way to understand origin 4

5 What is missing? Think to airport security checks for internal flight: Officers usually do not connect to any remote system They simply check offline the validity of the ID card: Check document expiration date and state at a glance Check that the photo matches owner s face Why? Because they trust the document Actually they trust who made the card card maker entitles card owner to cross the border {KprivA, KpubA} is not enough A third party trusted by everyone is missing Its signature on KpubA might fill the gap. Check how 5

6 Cryptographic certificates A cryptographic certificate CERT ID links an identifier (a name) to a public key CERT ID := {ID,K pubid } The link is guaranteed by a Certification Authority (CA) by means of the CA s signature on the certificate If you trust a CA, together with its certification and identification practices, you will trust its certificates: in other words, you will trust the links it has signed between identities and public keys In order to verify such link, you need an authentic copy of the CA public key Alice Alice CA Bob K puba Verify K puba?? K pubca CERT A ={S CA (K puba, A), K puba } Bob Verify K puba = Verify S CA 6

7 Public Key Infrastructures (PKI) A PKI defines protocols, policies and mechanisms needed to guarantee the authentication of public keys A PKI architecture needs: The specification of how certificates are formatted The definition of how relationships between several CAs, and between CAs and users, work Policies and mechanisms to issue and revoke certificates Directory services 7

8 X.509 certificates Standard version number + other data CA s identity User s identity User s public key CA s signature on all of the above Derived from ITU-T X.500 set of specifications, originally meant to cover everything a telecom operator would need to deploy effective directory services X.509 specifies everything related to authentication services Format: <object=property>, encoded in ASN.1 Note: the figures here group information logically. In actual certificates the order might be different 8

9 X.509 certificates Standard version number + other data CA s identity User s identity User s public key CA s signature on all of the above X.509 version 1, 2 or 3 Validity period Certificates should not be used outside of their validity period Serial number The pair <CA, serial number> must be unique Extensions: optional and defined only in version 3 For example, fields that indicate what kind of usage is permitted for this certificate 9

10 X.509 certificates Standard version number + other data CA s identity User s identity User s public key CA s signature on all of the above Identity s format is specified by X.500 Examples: Issuer: C=IT, ST=BS, L=Brescia, O=UniBS, OU=DEA, CN=Test CA Subject: C=IT, ST=BS, L=Brescia, O=UniBS, OU=DEA, CN=argo.ing.unibs.it The field CN (Common Name) is the primary identifier In Issuer, it identifies the CA In Subject, it identifies the user, i.e., the identity which owns the public key which this certificate is about 10

11 X.509 certificates Standard version number + other data CA s identity User s identity The public key that is being certified It must specify everything is required to use the public key The cryptosystem (RSA, DSS, ) Parameters. For RSA: Modulus n, and its size Public exponent e User s public key CA s signature on all of the above 11

12 X.509 certificates MDC Standard version number + other data CA s identity User s identity User s public key CA s signature on all of the above Signature Alg. K privca The certificate s authenticity and integrity are protected by the CA s signature The signature contains: The type and parameters of algorithms used for generating the signature For example: SHA-1 encrypted with the CA s private RSA key The actual signature s bytes 12

13 Revoking certificates Any certification system must specify and implement revocation mechanism Examples of public key revocation: When the corresponding private key has been compromised (stolen) When the corresponding private key has been lost When the key is no longer used, for example when the owner has changed jobs Two main revocation mechanisms Implicit: expiration date Explicit: actual revocation by the CA Analogy: credit cards 13

14 Explicit revocation Certificate Revocation Lists (CRL) Every CA periodically issues the CRL, a list of certificates that have been revoked (before their expiration date) The list contains: Issuer Last update date Next update date List of revoked certificates serial numbers, with the revocation date The CA s digital signature protects all of the above It would be good practice to verify that a given certificate does not appear on the CRL of the issuing CA, before using it Every user should periodically download the CRL from every CA they trust If the CRL is expired, and the CA cannot be contacted, certificates issued by such CA should not be used, until a current CRL can be obtained Many implementations today skip these tests Online Certificate Status Protocol has been recently defined, but it is not widely used 14

15 Distributing K pubca To verify the validity of a certificate, we need an authentic copy of the public key of the CA that has issued it: this is the same problem, albeit on a much smaller scale, that we started from K pubca is usually distributed as a CERT CA : A self-signed certificate, if the CA is a root CA A certificate issued by another CA in other cases So far, the best solution that has been proposed is to include dozens of selfsigned root CA certificates on every piece of software that needs to use certificates Operating systems Applications (web browsers, readers ) Cellular phones The problem could be solved more easily by deploying and using an efficient directory system, with an efficient global policy for handling CA hierarchies: we are still far from there 15

16 Distributing CERT X Ideal system: directory service Analogy with, or even integrated with, the DNS In this case A can start an authentication run with B without exchanging certificates: they can be downloaded from the directory service So far this approach has only been implemented at local levels, using LDAP The majority of applications today exchange certificates before executing an authentication run 16

17 Examples Examples of a root CA certificate, with issued certificates Examples from keychain 17

18 PKI architectures: how many CAs? Several possible approaches Monopoly: a single, global CA Variant: a single root CA, with a CA hierarchy under it Oligarchy: several root CA, all at the same level Oligarchy/hierarchy: several root CA, with delegation of namespaces to other CAs, similarly to what happens with the DNS Anarchy: no CA (or, better, everybody is a CA) In this case certificates are generated directly by the users (PGP model) The only global models in use today are the oligarchy and the anarchy Ongoing efforts to define and implement a hierarchic structure, based on mechanisms that validate certificate chains towards one or more root CA, and then towards end users 18

19 Managing a Certification Authority The importance of K privca The security of a CA-based system relies on: The security of the mechanism used to distribute the CA s certificate, which needs to ensure its integrity and authenticity The protection of K privca The CA and its K privca must be kept offline, disconnected from the Internet or, even better, from any network Identifying users before issuing certificates Before issuing CERT A, the CA must ascertain A s identity, and must verify that K puba is really A s public key Policies can vary from CA to CA: Returning can be OK as a form of identity verification for regular users Verifying a company s identity by checking with legal authorities can be required for more serious uses There is a lack of standardized procedures 19

20 Who uses X.509 certificates Any asymmetric-key authentication protocol can use certificates Example: STS Many network security protocols: SSL/TLS IPSec Many EAP methods used in and networks S/MIME 20

21 Security of authentication systems based on CAs and certificates Certificates are public, and do not need any form of extra cryptographic protection The CA s signature protects their integrity and authenticity CA vs. KDC There is no equivalent to the KDC s user database (that can be stolen, read, etc.) CAs are usually offline Even if the computer that hosts a CA breaks, systems can continue to authenticate using certificates issued by such CA Even the most dangerous attacks to a CA are usually less problematic to handle than the corresponding ones that can be mounted on a KDC The worst case scenario is when the attacker can issue false certificates Issuing false CRLs: in the worst case, users will not be able to communicate An attacker, even by gaining knowledge of K privca, cannot decipher any data protected by the certificates (actually, the private keys related to the certificates) issued by the CA 21

22 This subject (as usual) would require much more time CA chains and their policies Namespaces for CAs Registration authorities 22