English subtitles

← Signature Validation - Applied Cryptography

Get Embed Code
1 Language

Showing Revision 2 created 05/25/2016 by Udacity Robot.

  1. In order to trust the certificate, the client needs to validate that signature.
  2. To do that it needs to know the corresponding public key.
  3. It needs to know that public key that can be used to decrypt this message.
  4. If it decrypts it, it can check that this hash value is the same as what it computes
  5. when it hashes the certificate content itself.
  6. That is the real problem that public key infrastructure needs to solve.
  7. We need ways of distributing these public keys.
  8. That's called public key infrastructure, also known as PKI.
  9. We need a way to securely know the public key of the issuer.
  10. Once we know that we can use the certificate to learn the public key of the website we visited.
  11. How do we know that public key?
  12. Let's look back at the certificate that we got from Google.
  13. What we see at the top of it is the certificate hierarchy.
  14. We see that we have the google.com certificate, and that's the one we looked at
  15. and saw that it had this public key.
  16. That was signed by an issuer, and that issuer was Thawte, and we can click on that.
  17. Now we can see the certificate from Thawte that was used to sign this certificate.
  18. We have this certificate from Thawte. It was issued by VeriSign.
  19. We can check that it's valid. It's valid until 2014.
  20. That certificate also has a public key.
  21. It's got a subject identifying Thawte Consulting that generated the key.
  22. It's got a public key. It's also got an RSA key with PKCS.
  23. We can see that public key.
  24. That's the public key that we can use to validate the certificate that RSA provided.
  25. We can use that to decrypt the signed hash to validate that certificate.
  26. This would only be useful if we knew that we could trust this public key.
  27. How do we trust this public key?
  28. Well, it's got a certificate.
  29. It's certificate was issued by VeriSign.
  30. We can find VeriSign's public key to verify this one.
  31. That's the top of the certificate hierarchy here.
  32. We have a certificate from VeriSign, and if we look at that one--
  33. well, it came from VeriSign, and it's got a public key, also an RSA key and this one.
  34. You'll notice that all of them use 65,537 as their exponent.
  35. The moduli are all different.
  36. If they weren't different, that would mean they were all using the same public key,
  37. which would be a pretty serious problem.
  38. If we look at this key, we can see that it's expiration date is all the way up to 2028.
  39. It goes back to 1996. This is a very long-lived key.
  40. This is the key that is the root of our certificate hierarchy.
  41. Here's what we have. We have a certificate that was sent by Google.
  42. It was signed using a private key owned by Thawte Consulting.
  43. To validate that we need the corresponding public key, which we get from a certificate
  44. that was signed by VeriSign.
  45. To verify that, we need the public key for VeriSign.
  46. We have that from a certificate, which says it's VeriSign's.
  47. How can we trust VeriSign's certificate
  48. or do we have to keep going on forever?