Public key infrastructure x.509. Pehr Söderman Natsak08/DD2495

Transcription

1 Public key infrastructure x.509 Pehr Söderman Natsak08/DD2495 1

2 Terminology CA: Certification Authority RA: Registration Authority x.500: Electronic Directory Services x.509: Authentication framework 2

3 Certificates Uses asymmetric/public key cryptography Binds an Identity to information and key material Has an issuer, a subject and a verifier 3

4 Trust anchors A public key trusted to sign certificates Implicit trust Basis for any PKI system Might be a part of a certificate (also known as root certificates) Most vulnerable point of any PKI At some point we must decide to trust a key for noncryptographic reasons 4

5 Trust models Describes how trust is distributed from the trust anchors Describes the relationships between certificates Based on trust anchors Finds a trustworthy public key for an identity Two major paradigms: Chain of trust Web of trust 5

6 Chains of trust Form a chain of certificates to a trust anchor (Usually) Hierarchical structure Certificates have relationships such as parent, child or sibling 6

7 Monopoly A single CA acting also as RA One key to rule them all... All signing is done with this single key Frequently used for software distribution Can be used inside an administrative domain No certificate chains The single certificate can be embedded in all software that needs it Problems? 7

8 Monopoly with multiple RA Split up the RA and CA Still just one key Used when an organization does not wish to take the CA responsibility You have to trust both the CA and the RA for the certificate Problems? 8

9 Delegated CAs One trust anchor Signing permission can be delegated Multiple CA/RA CA's might be limited to part of the namespace You have to trust the anchor and all certificates in the chain Problems? 9

10 Oligarchy Most common model (used by browsers) Multiple trust anchors Each trust anchor forms a chain similar to Delegated CA's No single point of failure Multiple catastrophic points of failure Cross-signing Problems 10

11 Chain of trust summary Efficient Centralized structure Well suited for administrative control Absolute trust Reliance on a limited number of trust anchors Catastrophic failures 11

12 Chain of Trust: Common Failures Rough trust anchors Reliance on local data Sneak in an extra root certificate... Rough certificates Is the RA trustworthy? Is the CA trustworthy? Self-signed certificates Break one trust anchor, break all browsers in the world 12

13 Web of trust (Anarchy) Used by PGP Your own certificate is your trust anchor Trust from the number of relationships Mimics human relationships/trust Trust score is assigned by trust paths Short paths give higher trust More paths give higher trust Trust score is a sliding scale, not binary. 13

14 Web of trust Requires a (non-trusted) database of users Trust is a graph problem Scaling problems Administrative problems No single point of failure No catastrophic failure modes How do I get a secure connection to somebody far away...? 14

15 Web of Trust (Common failures) Attacks using multiple identities How to handle the lack of a path 15

16 Naming Hierarchical names DNS x.500 Normal names Important to distinguish identities 16

17 Naming constraints Naming constraints limits impacts of failures Limit CA to a specific namespace The book mentions several systems that are not used Bottom up constraints Relative names 17

18 Top-down constraints A certificate can only certify things on a lower level. Root certificate is trust anchor. nada.kth.se can only sign for *.nada.kth.se Multiple roots with overlapping namespaces are possible Global namespace Naming constraints are checked by going from the root and down Commonly deployed 18

19 Policies Implementation dependent In PEM: Policies for the whole hierarchy of certificates In x.509: OID tags identifying policies for specific certificates Resolving conflicting or equivalent policies is complicated. 19

20 Revocation What do we do when somebody stole our private key? We revoke it! But how...? 20

21 Certificate Revocation Lists Each CA regularly generates a list of invalid certificates it has signed. The user downloads the CRL before verifying a certificate from the CA If the Certificate is in the CRL it's invalid CRL can get very large Delta-CRL Full-CRL Does people check CRL? 21

22 On-line Revocation Server Allow users to check the CRL in real time Uses Online Certificate Status Protocol (OCSP) Adds an on-line part to the PKI OLRS can issue revocation certificates This proves a certificate was valid at a specific time 22

23 PKI on the Internet We need a directory service DNS x.500 Or do we? We need an encryption protocol SSL/TLS PGP We need a way to get the certificates 23

24 x.509 and PKIX PKIX is a profile, defining how to use x.509 x.509 is the defacto standard for PKI today on the internet Now we begin with the gritty details of certificates. 24

25 Naming x.509 is built on x.500. Therefor x.500 names. Typical naming: CN = secure.skandiabanken.se OU = SkandiaBanken AB O = Forsakringsaktiebolaget Skandia (publ) L = Stockholm ST = Stockholm C = SE How do we map this mess to Internet names? 25

26 Naming Invent your own field Use SubjectAltName field SSL Ask the user Look at the CN field Use SubjectAltName 26

27 OID Hierarchical numbers Might be familiar from SNMP Formated as An organization can get an OID and is free to assign meanings to numbers in that space Doublets are possible (and common) Published lists of common OID's exist 27

28 Information in a certificate All this information is signed All this information is in a human readable format For large values of human 28

29 Header information Version Serial Number Unique ID of the certificate together with the CA. Used for revocation. Signature Signature algorithm used Validity Start end end time for the certificate 29

30 Issuer information Issuer x.500 name of the issuer IssuerUniqueIdentifier UID of issuer, deprecated 30

31 Subject information Subject x.500 name of the subject SubjectPublicKeyInfo Defines the algorithm and the public key for this subject SubjectUniqueIdentifier UID of the subject. Deprecated. 31

32 Trailer AlgorithmIdentifier/SignatureAlgorithm Dublicate of the previous subject field Redundant Encrypted/SignatureValue The actual signature of the certificate 32

33 Extensions (KeyUsage) DigitalSignature NonRepudiation KeyEncipherment DataEncipherment KeyAgreement KeyCertSign CRLSign EncipherOnly DecipherOnly 33

34 Extensions (Certificate Policies) List of OID Defines the policies used when the certificate was generated Allows the user to ignore certificates that doesn't match his policies 34

35 Extensions (PolicyMappings) Allows the mapping of one OID to an equialent one For example 1.2.6=1.2.3 First OID must be in issuer domain Second OID must be in Subject domain 35

36 Extensions (AltName) SubjectAltName Secondary name used to identify the subject Commonly used to map to Internet names IssuerAltName Similar function 36

37 Extensions (Constraints) BasicConstraints Allows certificate to be a CA (Dublicate) NameConstraints Limits the namespace the certificate can be CA for PolicyConstraints Limits OID mappings and forces OID inclusions 37

38 Extensions (CRL, Info) CRLDistributionPoints Defines where to find CRL FreshestCRL Describes how to find a deltacrl SubjectInfoAccess Describes how to find more information about the subject 38

39 CRL (Header fields) Signature Signature algorithm Issuer X.500 name of the issuer ThisUpdate Time stamp for this update NextUpdate Timestamp for the next update (optional) 39

40 CRL (Revocations) UserCertificate Serial number of the certificate RecovationDate Time of the recovation CrlEntryExtensions and CrlExtensions Additional information, such as why the recovation was done Algorithm Identifier and Encrypted Signature of the revocation 40

41 Common attacks on x.509 Attacks on the users Man in the middle attacks on self-signed certificates (no chain) Weak hash algorithms (md5) Get a certificate for somebody else Software that forgets to check constraints (everybody is a CA) Remember, just because you know who you are talking to doesn't mean he is nice Phishing! 41

42 Most important Can you trust your CA? 42

43 Lets have a look at a real certificate 43