1 / 28

Security course PKI (Public key insfrastructure)

Security course PKI (Public key insfrastructure). Jean-Roland Schuler jroland.schuler@eif.ch. Key management. The key management is a difficult problem: The main problem is the human factor don ‘t give a key 1’000’000 Fr

lawrencia-benedict
Download Presentation

Security course PKI (Public key insfrastructure)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security coursePKI (Public key insfrastructure) Jean-Roland Schuler jroland.schuler@eif.ch

  2. Key management • The key management is a difficult problem: • The main problem is the human factor • don ‘t give a key • 1’000’000 Fr • We can resolve the technical factors but the human factors are not easy to resolve

  3. Symmetric key distribution Small number entities Great number entities

  4. Key distribution center • Shared session key between KDC and hosts • Needham-Schroeder (Kerberos base) • Problem: Shared session key distribution

  5. Diffie-Hellman • Creates symmetric keys between two or more persons and the keys are never transfered between the persons • DH is used by SSH, IPSec

  6. Diffie-Hellman • Bob sends an initial request to Alice • Alice choises 2 great prime numbers: n and g • She generates a random number: y(y = private key) • She computes: Y = gy mod(n). (Y = public key) • She sends back the values: Y, g, n

  7. Diffie-Hellman • Bob generates a random value: x (x=private key) • He computes: X = gx mod(n). (X = public key) • He sends his public key (X) to Alice

  8. Diffie-Hellman • Bob and Alice can now compute the symmetric key • X, x: Bob’s public/private keys • Y, y: Alice’s public/private keys • Bob: k = Yx mod(n) = ((gy mod(n)) x mod(n). • Alice: k’ = Xy mod(n) = ((gx mod(n)) y mod(n). • We can prove: • ((gy mod(n)) x = ((gx mod(n)) y k=k’

  9. Diffie-Hellman

  10. Jack and Diffie-Hellman • Jack can know the values: n, g, X, Y • Jack knows the Diffie-Hellman algorithm • Jack knows the symmetric key egual: k = Yx mod(n) • Jack knows Y, n, but not x (Alice’s private key) • Jack knows X and this formula: X = gx mod(n)  it is very hard to find x with this formula

  11. Public key importance • Digital signature • Authentication • Non-repudiation • Bob must know Alice’s public key

  12. Public Key Infrastructure, PKI • The CA knows the public keys of Bob, Alice, Marcel • Every public key is stored in a digital certificate • If Bob will ‘speak’ with Alice, he asks the CA, and the CA sends the Alice digital certificate or Alice can send to Bob her certificate, but Bob must check if the certificate is valid

  13. CA-Certificate Authority • The certificate authority (CA) is the trusted third party • The CA: • enrolls certificate (RA: Registration Authority) • checks the informations given by a person or compagny • distributes the certificates • revokes the certificates

  14. Certificate Request • Bob creates his public and private keys • Bob writes a certificate request • Bob sends the request to the CA • The CA checks the validity of the request • The country authority sends back the check • The CA sends the signed certificate

  15. Certificate Request • Bob checks the certificate signature • Bob must have the CA certificate • Verisign, Entrust certificates are included in Netscape

  16. Bob and Alice certificates • Bob and Alice exchange their certificates • Bob and Alice check the received certificates with the CA’s certificate

  17. CA certificates • Perhaps the CA of Bob is not the same CA of Alice • Alice must have the CA’s certificate of Bob

  18. Jack and Alice certificates • Jack creates a new certificate and tell ‘I’m Bob’ and signed himself the certificate • Jack sends this false certificate to Alice • Alice don’t know the CA and don’t accept the certificate

  19. Certificate and Passport 1 1: Passport number 2: Authority name 3: Validity 4: Person identity 5: Signature 6: Description 7: Authority sign. 4 7 5 6 3 2: on another page

  20. Certificate and Passport Certificate: Data: Version: 3 (0x2) Serial Number: 4 (0x4) Signature Algorithm: md5WithRSAEncryption Issuer: C=CH, ST=Fribourg, L=Fribourg, O=Ecole Ingenieurs de Fribourg, OU=Section Informatique, CN=CA EIF Validity Not Before: May 30 15:53:57 2001 GMT Not After : May 30 15:53:57 2002 GMT Subject: C=CH, ST=Fribourg, L=Fribourg, O=Ecole Ingenieurs de Fribourg, OU=Section Informatique, CN=Client SSL Chat Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a7:8e:78:d4:44:4c:c9:e8:c7:6e:31:ab:a6:73: f5:ad:f6:08:68:6e:b9:bb:a8:25:0b:0b:80:78:a9: e3:90:81:fa:0b:56:c7:2f:55:6a:16:f0:fc:e2:4b: 6c:82:35:e8:34:94:60:0e:65:10:f9:fa:d0:83:d9: b3:41:78:d5:19:a7:5c:9d:f8:dc:d2:25:72:bc:84: f0:e7:88:3e:85:2d:ed:be:c8:01:2a:58:c1:76:35: 9c:85:59:31:48:a5:0c:77:24:f8:ea:a4:03:30:16: 7e:21:e5:f5:b7:47:f7:08:8d:64:1f:d3:0e:64:5d: a9:77:3f:c1:2b:f0:85:19:87 Exponent: 65537 (0x10001) 1, certificate number 2, CA name 3, validity 4, user identity 5, user public key

  21. Certificate and Passport X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 07:BB:BF:E3:DF:9D:10:D4:8A:FE:53:60:7B:BB:CF:3C:88:41:E1:43 X509v3 Authority Key Identifier: keyid:08:73:25:C5:E0:A5:13:B3:3B:85:85:AC:C2:9F:3C:8A:F7:62:64:FD DirName:/C=CH/ST=Fribourg/L=Fribourg/O=Ecole Ingenieurs de Fribourg/OU=Section Informatique/CN=CA EIF serial:00 Signature Algorithm: md5WithRSAEncryption 62:9f:cc:19:c7:b7:d5:02:f5:00:4e:4c:a8:64:8c:4e:d8:26: 3f:29:50:4c:38:19:fc:b9:a3:32:f8:c8:6a:e9:f7:64:6a:8b: 39:a6:33:c8:60:6b:f1:37:12:e2:3d:dd:80:47:a9:06:c4:c6: 17:b6:04:87:aa:93:8d:fc:e5:a1:0e:65:50:08:b9:da:23:85: 38:06:d6:ba:5e:2e:13:9a:a2:75:7a:4f:44:78:9e:63:09:c2: 4e:f5:08:22:bf:0e:94:1b:e1:52:4d:b1:99:32:6d:6b:43:bd: 02:d4:b4:76:1b:e7:68:a4:c0:69:b5:58:93:f0:01:60:bf:fd: 8d:50 6, options 7, ca signature

  22. X.509 and ASN.1 • The X.509 standard is a subset of the X.500 norm • X.500 is a global directory • The actual version of X.509 standard is the 3 • The X.509 standard uses the ASN.1 (Abstract Syntax Notation) notation which describes the contents of the certificate

  23. Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version must be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version must be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version must be v3 } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER   Validity ::= SEQUENCE { notBefore CertificateValidityDate, notAfter CertificateValidityDate }   CertificateValidityDate ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime }   UniqueIdentifier ::= BIT STRING   SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }   Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension   Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } ASN.1 format

  24. DER format • The ASN.1 notation describes the certificate contents • The DER (Distinguished Encoding Rules) is the binary representation of the certificate • OpenSSL command: • openssl x509 -inform DER -in Certificat.der -noout -text

  25. PEM format • The DER format uses the 8th bit of the byte • Some E-mail program don’t support that. • PEM (Privacy Enhanced Mail) uses the base 64 encoding: • Every line has 64 bytes length (except the last) • Every character is included between [A-Z a-z 0-9 / +],  64 characters  6 bits 8 bits 8 bits 8 bits 6 bits 8 bits 8 bits 8 bits

  26. PEM format -----BEGIN CERTIFICATE----- MIIDrTCCAxagAwIBAgIBBDANBgkqhkiG9w0BAQQFADCBijELMAkGA1UEBhMCQ0gx ETAPBgNVBAgTCEZyaWJvdXJnMREwDwYDVQQHEwhGcmlib3VyZzElMCMGA1UEChMc RWNvbGUgSW5nZW5pZXVycyBkZSBGcmlib3VyZzEdMBsGA1UECxMUU2VjdGlvbiBJ bmZvcm1hdGlxdWUxDzANBgNVBAMTBkNBIEVJRjAeFw0wMTA1MzAxNTUzNTdaFw0w MjA1MzAxNTUzNTdaMIGTMQswCQYDVQQGEwJDSDERMA8GA1UECBMIRnJpYm91cmcx ETAPBgNVBAcTCEZyaWJvdXJnMSUwIwYDVQQKExxFY29sZSBJbmdlbmlldXJzIGRl IEZyaWJvdXJnMR0wGwYDVQQLExRTZWN0aW9uIEluZm9ybWF0aXF1ZTEYMBYGA1UE AxMPQ2xpZW50IFNTTCBDaGF0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn jnjUREzJ6MduMaumc/Wt9ghobrm7qCULC4B4qeOQgfoLVscvVWoW8PziS2yCNeg0 lGAOZRD5+tCD2bNBeNUZp1yd+NzSJXK8hPDniD6FLe2+yAEqWMF2NZyFWTFIpQx3 JPjqpAMwFn4h5fW3R/cIjWQf0w5kXal3P8Er8IUZhwIDAQABo4IBFjCCARIwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlm aWNhdGUwHQYDVR0OBBYEFAe7v+PfnRDUiv5TYHu7zzyIQeFDMIG3BgNVHSMEga8w gayAFAhzJcXgpROzO4WFrMKfPIr3YmT9oYGQpIGNMIGKMQswCQYDVQQGEwJDSDER MA8GA1UECBMIRnJpYm91cmcxETAPBgNVBAcTCEZyaWJvdXJnMSUwIwYDVQQKExxF Y29sZSBJbmdlbmlldXJzIGRlIEZyaWJvdXJnMR0wGwYDVQQLExRTZWN0aW9uIElu Zm9ybWF0aXF1ZTEPMA0GA1UEAxMGQ0EgRUlGggEAMA0GCSqGSIb3DQEBBAUAA4GB AGKfzBnHt9UC9QBOTKhkjE7YJj8pUEw4Gfy5ozL4yGrp92RqizmmM8hga/E3EuI9 3YBHqQbExhe2BIeqk4385aEOZVAIudojhTgG1rpeLhOaonV6T0R4nmMJwk71CCK/ DpQb4VJNsZkybWtDvQLUtHYb52ikwGm1WJPwAWC//Y1Q -----END CERTIFICATE-----

  27. PKCS format • PKCS is a norm developped by the RSA laboratories • PKCS#1: RSA encryption standard • PKCS#5: Password-Based Encryption Standard • PKCS#7: Cryptographic Message Syntax Standard • PKCS#8: Private-key Information Syntax Standard • PKCS#10: Certification Request Syntax Standard • PKCS#12: Personal Information Exchange Syntax Standard

  28. References • Cryptographie appliquée, Bruce Schneier, 2e edition, WILEY, 1997, 2-84180-036-9 • Cryptographie, Théorie et Pratique, Douglas Stinson, 1996, 2-84180-013-X • Développement d’applications sécurisées, Daniel Bruegger, 2001, Ecole d’Ingénieurs et d’architectes de Fribourg

More Related