certificates and network security - ?· certificates and network security. outline x.509...

Download Certificates and network security - ?· Certificates and network security. Outline X.509 certificates…

Post on 28-Jul-2018

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Tuomas AuraT-110.4206 Information security technology

    Certificates and network security

  • Outline

    X.509 certificates

    Network security basics

    Secure socket layer

    (More in the course T-110.5240 Network security, period II)

    2

  • X.509 CERTIFICATES

    3

  • Key distribution problem Public keys make key distribution easier than it is for

    secret keys, but it is still not trivial: How to find out someones authentic public key?

    Solution: an authority issues certificates that bind public keys to names

    Certificate = SignCA (Name, PK, validity dates)

    Message signed by the authority, containing the subject name and public key

    Questions: Who could the authority be?

    How does everyone know the public key of the authority?

    What is the difference between authority and trusted third party?

    4

  • X.509 PKI ITU-T/ISO X.509 standard, IETF RFC3280 Certification authority (CA) issues certificates

    CA can delegate its authority to another CA CA hierarchy

    X.509 certificates are identity certificates i.e. bind a principal name to a public key

    Users, computers and services are end entities CAs and end entities are principals

    Each principal has a key pair Key pair = public and private signature key

    (RSA keys can also be used for encryption)

    Standard notation for a certificate: CA

    5

  • 6

    Certificate:

    Data:

    Version: 3 (0x2)

    Serial Number:

    d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c

    Signature Algorithm: sha1WithRSAEncryption

    Issuer: C=FI, O=Sonera, CN=Sonera Class2 CA

    Validity

    Not Before: Nov 19 12:02:09 2009 GMT

    Not After : Nov 19 12:02:09 2010 GMT

    Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin.tkk.fi/emailAddress=webmaster@tkk.fi

    Subject Public Key Info:

    Public Key Algorithm: rsaEncryption

    RSA Public Key: (1024 bit)

    Modulus (1024 bit):

    00:c7:94:9b:49:29:6f:2d:6d:32:70:97:73:39:1e:

    04:20:89:ea:05:89:02:01:1a:d7:2d:ad:86:f6:99:

    69:7e:13:19:f2:09:d0:e6:05:ca:93:13:a7:e2:7b:

    3b:b6:68:e7:49:c7:3b:53:fd:b5:c1:bc:64:65:6c:

    4d:89:37:ab:b5:6b:2a:38:2b:45:82:f6:99:97:21:

    57:fc:ac:26:9b:04:3b:ad:13:26:8e:85:ff:44:ba:

    4f:1e:27:cc:f2:fd:c1:47:c4:de:b6:d2:6c:2c:48:

    6e:a3:cc:cd:0c:ed:75:4b:a2:c7:f0:c2:e1:9b:e9:

    d3:0c:1b:90:35:c8:ee:e7:01

    Exponent: 65537 (0x10001)

    X509v3 extensions:

    X509v3 Authority Key Identifier:

    keyid:4A:A0:AA:58:84:D3:5E:3C

    X509v3 Certificate Policies:

    Policy: 1.3.6.1.4.1.271.2.3.1.1.2

    X509v3 CRL Distribution Points:

    URI:ldap://194.252.124.241:389/cn=Sonera%20Class2%20CA,o=Sonera,c=FI?certificaterevocationlist;binary

    X509v3 Key Usage:

    Digital Signature, Key Encipherment

    X509v3 Extended Key Usage:

    TLS Web Server Authentication, TLS Web Client Authentication

    X509v3 Subject Key Identifier:

    86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7

    Signature Algorithm: sha1WithRSAEncryption

    50:c3:94:71:b3:d2:1d:7f:be:71:5e:fe:ff:ec:09:50:68:f0:

    27:54:cd:e8:f2:17:90:3e:ea:6c:e2:81:12:bf:e2:73:72:9e:

    02:d3:b4:03:88:2a:6a:b1:00:ca:70:24:1b:3f:da:d6:30:46:

    X.509 certificate exampleSave certificate into a file and pretty print:% openssl x509 -in cert.pem -noout -text

    Subject name

    Subject public key

    Issuer info

    Validity dates

    Key usage

    CA signature

    Revocation list URL

  • X.509 certificate fields (1)Mandatory fields: Version Serial number together with Issuer, uniquely

    identifiers the certificate Signature algorithm for the signature on this

    certificate; usually sha1RSA; includes any parameters Issuer name (e.g. CN = Microsoft Corp Enterprise CA

    2) Valid from usually the time when issued Valid to expiry time Subject distinguished name of the subject Public key public key of the subject

    7

  • X.509 certificate fields (2)Common extension fields: Key usage bit field indicating usages for the subject key

    (digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly)

    Subject alternative name email address, DNS name, IP address, etc. Issuer alternative name Basic constraints (1) is the subject a CA or an end entity, (2) maximum

    length of delegation to sub-CAs after the subject Name constraints limit the authority of the CA Certificate policies list of OIDs to indicate policies for the certificate Policy constraints certificate policies Extended key usage list of OIDs for new usages, e.g. server

    authentication, client authentication, code signing, email protection, EFS key, etc.

    CRL distribution point where to get the CRL for this certificate, and who issues CRLs

    Authority info access where to find information about the CA and its policies

    8

  • Certificate chain Typical certificate chain:

    1. Root CA self-signed certificate2. Root CA issues a CA certificate to a sub-CA3. Sub-CA issues end-entity certificate to a user, computer or

    web server

    Chain typically has 0..2 sub-CAs (Why?) Self-signed certificate is an X.509 certificate issued by CA to

    itself; not really a certificate, just a way to store and transport the CA public key

    9

  • CA hierarchy One root CA Each CA can delegate its

    authority to sub-CAs All end-entities trust all CAs

    to be honest and competent Original hope:

    One global hierarchy

    Reality: One hierarchy per

    organization Competing commercial root

    CAs without hierarchy, e.g. Verisign

    10

    Contoso

    Root CA

    PKCA

    Bob,

    PKB

    Charlie,

    PKC

    Contoso

    Sales CA

    PKSales

    Contoso

    Sales

    Asia CA,

    PKUS

    Contoso

    Sales

    Euro CA

    PKEuro

    Contoso

    Dev CA

    PKDev

    CA certificate

    End-entity

    certificate

    Alice,

    PKA

    David,

    PKD

  • Certificate path original idea How can Bob check Alices

    PK? Original idea

    En-entities (like Bob) know their nearest CA

    Each sub-CA certifies its parent CA in reverse direction

    CA path from root to Alicemeets reverse path from Bobs nearest CA to root at some point path from Bob to Alice

    In practice, implementations work differently: one path from root CA to end entity

    11

    Contoso

    Root CA

    PKCA

    Alice,

    PKA

    Bob,

    PKB

    Charlie,

    PKC

    Contoso

    Sales CA

    PKSales

    Contoso

    Sales

    Asia CA,

    PKUS

    Contoso

    Sales

    Euro CA

    PKEuro

    Contoso

    Dev CA

    PKDev

    David,

    PKD

    CA certificate

    End-entity

    certificate

    Self-certificate

  • 12

    Certificate path End-entities (e.g. Bob)

    know the root CA Root CAs PK stored as a

    self-signed certificate

    To verify Alices signature: Bob needs the entire

    certificate path from root CA to Alice (self-signed root certificate + 2 CA certificates + end-entity certificate)

    The root CA must be in Bobs list of trusted root CAs

    Contoso

    Root CA

    PKCA

    Alice,

    PKA

    Bob,

    PKB

    Charlie,

    PKC

    Contoso

    Sales CA

    PKSales

    Contoso

    Sales

    Asia CA,

    PKUS

    Contoso

    Sales

    Euro CA

    PKEuro

    Contoso

    Dev CA

    PKDev

    David,

    PKD

    CA certificate

    End-entity

    certificate

    Self-certificate

  • 13

    Certificate revocation When might CA need to revoke certificates?

    If the conditions for issuing the certificate no longer hold If originally issued in error If the subject key has been compromised

    Certificate revocation list (CRL) = signed list of certificate serial numbers

    Who issues the CRL? How to find it? By default, CRL is signed by the CA that issued the

    certificate CRL distribution point and issuer can be specified in each

    certificate

    Only certificates are revoked, not keys No mechanism for revoking the root key Unlike PGP

  • 14

    X.509 CRL fields

    Signature algorithm

    Issuer name

    This update time

    Next update time

    For each revoked certificate: Serial number

    Revocation date (how would you use this information?)

    Extensions reason code etc.

    Signature

  • 15

    Setting up a PKI

    Potential root CAs: Commercial CA such as Verisign, Sonera, etc. usually

    charges per certificate

    Windows root domain controller can act as an organizational CA

    Anyone can set up their own CA using Windows server or OpenSSL

    The real costs: Distributing the root key (self-signed certificate)

    Certificate enrolment need to issue certificates for each user, computer, mobile device etc.

    Administering a secure CA and CRL server

    !

  • Name and identity With certificates, it is possible to authenticate the name or

    identifier of an entity e.g. person, computer, web server, email address

    What is the right name anyway? wwwlogin.tkk.fi, security.tkk.fi, leakybox.cse.tkk.fi George Bush, George W. Bush, George H. W. Bush tuomas.aura@aalto.fi, aura@cs.hut.fi, aaura@hut.fi, taura@cse.tkk.fi,

    aura@cse.tkk.fi

    Who decides who owns the name? aalto.fi Ville Valo on Facebook

    Identity proofing: How is the identity of the subject verified? Email Extended validation certificates

    Does knowing the name imply trust? Should I order a second-

Recommended

View more >