Encryption An Overview
Fundamental problems <ul><li>Internet traffic goes through many networks and routers </li></ul><ul><li>Many of those netwo...
Security Issues <ul><li>Eavesdropping </li></ul><ul><li>Tampering </li></ul><ul><li>Impersonation </li></ul><ul><ul><li>Sp...
General Areas <ul><li>Encryption/Decryption </li></ul><ul><li>Indentification/Authentication </li></ul><ul><li>Authorizati...
Private Key Encryption Message Encrypted Message PrivateKey Encryption Algorithm Message Decryption Algorithm PrivateKey K...
Public  Key Encryption Message Encrypted Message PublicKey Encryption Algorithm Message Decryption Algorithm PrivateKey Pu...
Public  Key Encryption - reverse Message Encrypted Message PublicKey Encryption Algorithm Message Decryption Algorithm Pri...
Encryption/Decryption Algorithm <ul><li>Private or public key </li></ul><ul><li>Size of key  </li></ul><ul><ul><li>Harder ...
Lots of Algorithms in use <ul><li>DES </li></ul><ul><li>DSA </li></ul><ul><li>MD5 </li></ul><ul><li>RC2 and RC4 </li></ul>...
Identification/Authentication <ul><li>Certificate from Certificate Authorities </li></ul><ul><li>Key is to trust the CA ag...
Public Key Certificate (Bill <--> Mary) User Public key Identity (Bill) Signing Process Digital Signature CA Agency Privat...
Digital Signature  Tamper Detection Message (maybe big) Hash Algorithm (MD5) Hash Value Private key Encrypt Hash (RSA) Enc...
Authorization <ul><li>Often overlooked </li></ul><ul><li>Not encryption but related </li></ul><ul><li>Once authenticated, ...
Nonrepudiation <ul><li>When using an electronic signature </li></ul><ul><li>Can the person deny it actually came from them...
SSL <ul><li>Rides over the transport layer </li></ul><ul><li>Uses certificates for authentication </li></ul><ul><ul><li>Se...
SSL handshake from  docs.sun.com <ul><li>The client sends the server the client's SSL version number, cipher settings, ran...
Typical Client check of SERVER CA (from docs.sun.com) Client CA check is similar
SSH <ul><li>Much simpler </li></ul><ul><li>Server contacts the client and asks if the client will accept the  public  key ...
Upcoming SlideShare
Loading in...5
×

Encryption

849

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
849
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
45
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Encryption

  1. 1. Encryption An Overview
  2. 2. Fundamental problems <ul><li>Internet traffic goes through many networks and routers </li></ul><ul><li>Many of those networks are broadcast media </li></ul><ul><li>Sniffing allows for many to </li></ul><ul><ul><li>see transmissions </li></ul></ul><ul><ul><li>Tamper/alter transmission </li></ul></ul><ul><ul><li>Spoof identities </li></ul></ul>
  3. 3. Security Issues <ul><li>Eavesdropping </li></ul><ul><li>Tampering </li></ul><ul><li>Impersonation </li></ul><ul><ul><li>Spoofing </li></ul></ul><ul><ul><li>misrepresentation </li></ul></ul>
  4. 4. General Areas <ul><li>Encryption/Decryption </li></ul><ul><li>Indentification/Authentication </li></ul><ul><li>Authorization </li></ul><ul><li>Tamper Detection </li></ul><ul><li>Nonrepudiation </li></ul><ul><li>Example using SSL </li></ul><ul><li>Example using SSH </li></ul>
  5. 5. Private Key Encryption Message Encrypted Message PrivateKey Encryption Algorithm Message Decryption Algorithm PrivateKey Key distribution/Protection is Critical !
  6. 6. Public Key Encryption Message Encrypted Message PublicKey Encryption Algorithm Message Decryption Algorithm PrivateKey Public Key distribution/Protection is NOT Critical ! Only the Private Key will enable decryption
  7. 7. Public Key Encryption - reverse Message Encrypted Message PublicKey Encryption Algorithm Message Decryption Algorithm PrivateKey Use you own private key to encrypt Let others have your public key.. No one can spoof you Process is symmetric in the sense that private-encrypted can also ONLY be decoded with the public key
  8. 8. Encryption/Decryption Algorithm <ul><li>Private or public key </li></ul><ul><li>Size of key </li></ul><ul><ul><li>Harder to break/decipher </li></ul></ul><ul><ul><li>Key strength also related to algorthm </li></ul></ul><ul><ul><li>128bit private stronger than 128bit public </li></ul></ul><ul><li>Time Life of the key </li></ul><ul><ul><li>Crackable in a month, change every day </li></ul></ul><ul><li>Time to calculate </li></ul><ul><ul><li>Impact on communication delays </li></ul></ul><ul><ul><li>Private-key faster than public key techniques </li></ul></ul>
  9. 9. Lots of Algorithms in use <ul><li>DES </li></ul><ul><li>DSA </li></ul><ul><li>MD5 </li></ul><ul><li>RC2 and RC4 </li></ul><ul><li>RSA </li></ul><ul><li>SHA </li></ul><ul><li>SKIPJACK </li></ul>
  10. 10. Identification/Authentication <ul><li>Certificate from Certificate Authorities </li></ul><ul><li>Key is to trust the CA agency. </li></ul><ul><li>If two parties trust different CA agencies but the two trust each other, a hierarchical trust relationship can exist. </li></ul><ul><li>Problem scenario </li></ul><ul><ul><li>Bill publishes his public key for others (Mary) </li></ul></ul><ul><ul><li>Bob publishes a public key posing as Bill </li></ul></ul><ul><ul><li>Only a trusted CA can verify that Bill’s public key is really from Bill </li></ul></ul><ul><ul><li>Bill includes a digitally signed certificate from a CA attesting to the public key </li></ul></ul>
  11. 11. Public Key Certificate (Bill <--> Mary) User Public key Identity (Bill) Signing Process Digital Signature CA Agency Private Key Mary Decrypts CA Agency Public Key Accept or reject MARY MUST TRUST CA
  12. 12. Digital Signature Tamper Detection Message (maybe big) Hash Algorithm (MD5) Hash Value Private key Encrypt Hash (RSA) Encrypted Hash Value Send to receiver… checks by decrypting the hash with public key.. Small data to encrypt .. Detects tampering w/o encoding whole mesg.
  13. 13. Authorization <ul><li>Often overlooked </li></ul><ul><li>Not encryption but related </li></ul><ul><li>Once authenticated, is this person actually authorized, have the rights and permissions, to do what this user is asking. </li></ul>
  14. 14. Nonrepudiation <ul><li>When using an electronic signature </li></ul><ul><li>Can the person deny it actually came from them </li></ul><ul><li>Digital signatures are legal </li></ul><ul><li>For public/private key encryption, the only way that the signature could be invalid is if the private key was made public. </li></ul>
  15. 15. SSL <ul><li>Rides over the transport layer </li></ul><ul><li>Uses certificates for authentication </li></ul><ul><ul><li>Server authentication </li></ul></ul><ul><ul><li>Optionally client authentication </li></ul></ul><ul><ul><li>BROWSER must tust CA </li></ul></ul><ul><li>Sets up the communication using public-private keys to negotiate and establish symmetric private keys </li></ul><ul><li>Send rest of communication encrypted </li></ul>
  16. 16. SSL handshake from docs.sun.com <ul><li>The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL. </li></ul><ul><li>The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client's certificate. </li></ul><ul><li>The client uses some of the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to Step 4 . </li></ul><ul><li>Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in Step 2 ), and sends the encrypted premaster secret to the server. </li></ul><ul><li>If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own certificate to the server along with the encrypted premaster secret. </li></ul><ul><li>If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret. </li></ul><ul><li>Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity--that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection. </li></ul><ul><li>The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished. </li></ul><ul><li>The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished. </li></ul><ul><li>The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity. </li></ul>
  17. 17. Typical Client check of SERVER CA (from docs.sun.com) Client CA check is similar
  18. 18. SSH <ul><li>Much simpler </li></ul><ul><li>Server contacts the client and asks if the client will accept the public key as authentic </li></ul><ul><ul><li>Only server can decrypt </li></ul></ul><ul><li>Client says yes. </li></ul><ul><li>All is done. </li></ul><ul><li>Client can authenticate different ways </li></ul><ul><ul><li>Typically just with password. </li></ul></ul><ul><li>Negotiate a symmetric private key for the session </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×